jkp@SAUNA.HUT.FI (Jyrki Kuoppala) (08/23/89)
In article <890821-112651-1301@Xerox>, Leisner.Henr@XEROX (Marty) writes: >SunOS makes only puts the variables defined in the makefile, the command >line or inherited in the environment in the child's environment. GNUmake >puts everything into the environment, even variables never referenced (i.e. >like: >F77=$(FC) >F77FLAGS=$(FFLAGS) >FC=f77 Oh yes, this reminds me of the misfeature I ran into a few days ago. Some program (I don't remember which) had in it's rules lines like: SHELL = /bin/sh 1 = 1 (for the manual page extension). Then there was a shell script ran in the makefile. The shell bombs with `1=1: is not an identifier' on at least SVR2 and BSD 4.3 because it doesn't like environment variables with numbers. (By the way, Sun seems to have changed (fixed?) this, their /bin/sh as of Sunos 4.0.1 doesn't complain about the environment variable 1. So perhaps the make behaviour isn't desirable, at least it can cause harm in some rare causes. //Jyrki
mr-frog%scam.Berkeley.EDU@UCBVAX.BERKELEY.EDU (Dave "Human Decompiler" Pare) (09/04/89)
First of all, gnumake doesn't successfully compile on Ultrix
(Vax 88XX) 3.1 (Rev. 9) because sys/wait.h defines WTERMSIG,
and apparently gnumake interprets this as a Sign that it's on
a non-bsd machine, and starts running around getting confused.
Maybe I'm confused. I got 3.55 off uunet today, and tried
"/bin/make" after an uneventful uncompress and tar -xf. No
GNU-make files were modified -- should they have been?
Here's a copy of sys/wait.h from my ultrix machine:
---------
/* @(#)wait.h 4.1.1.2 (ULTRIX) 7/13/88 */
/*
* This file holds definitions relevent to the wait system call.
* Some of the options here are available only through the ``wait3''
* entry point; the old entry point with one argument has more fixed
* semantics, never returning status of unstopped children, hanging until
* a process terminates if any are outstanding, and never returns
* detailed information about process resource utilization (<vtimes.h>).
*/
/*
* Structure of the information in the first word returned by both
* wait and wait3. If w_stopval==WSTOPPED, then the second structure
* describes the information returned, else the first. See WUNTRACED below.
*/
union wait {
int w_status; /* used in syscall */
/*
* Terminated process status.
*/
struct {
unsigned short w_Termsig:7; /* termination signal */
unsigned short w_Coredump:1; /* core dump indicator */
unsigned short w_Retcode:8; /* exit code if w_termsig==0 */
} w_T;
/*
* Stopped process status. Returned
* only for traced children unless requested
* with the WUNTRACED option bit.
*/
struct {
unsigned short w_Stopval:8; /* == W_STOPPED if stopped */
unsigned short w_Stopsig:8; /* signal that stopped us */
} w_S;
};
#define w_termsig w_T.w_Termsig
#define w_coredump w_T.w_Coredump
#define w_retcode w_T.w_Retcode
#define w_stopval w_S.w_Stopval
#define w_stopsig w_S.w_Stopsig
#define WSTOPPED 0177 /* value of s.stopval if process is stopped */
/*
* Option bits for the second argument of wait3. WNOHANG causes the
* wait to not hang if there are no stopped or terminated processes, rather
* returning an error indication in this case (pid==0). WUNTRACED
* indicates that the caller should receive status about untraced children
* which stop due to signals. If children are stopped and a wait without
* this option is done, it is as though they were still running... nothing
* about them is returned.
*/
#define WNOHANG 1 /* dont hang in wait */
#define WUNTRACED 2 /* tell about stopped, untraced children */
/*
* Must cast as union wait * because POSIX defines the input to these macros
* as int.
*/
#define WIFSTOPPED(x) (((union wait *)&(x))->w_stopval == WSTOPPED)
#define WIFSIGNALED(x) (((union wait *)&(x))->w_stopval != WSTOPPED && ((union wait *)&(x))->w_termsig != 0)
#define WIFEXITED(x) (((union wait *)&(x))->w_stopval != WSTOPPED && ((union wait *)&(x))->w_termsig == 0)
#define WEXITSTATUS(x) (((union wait *)&(x))->w_retcode)
#define WTERMSIG(x) (((union wait *)&(x))->w_termsig)
#define WSTOPSIG(x) (((union wait *)&(x))->w_stopsig)
---------
I got curious, and loaded GNU make with saber. Here are a list of problems
saber found, ranging from the trivial to the possibly-dangerous. I didn't
include the dozens of "benign type mis-match -- signed int passed when
unsigned int expected", or the redeclared void procedures (was undeclared,
then was declared as void), as there were too many.
"commands.c":300, execute_file_commands(), Unused automatic variable
Automatic variable 'line' was not used.
"dir.c":92, find_directory(), Unused automatic variable
Automatic variable 'st' was not used.
"main.c":905, decode_switches(), Result of operator unused (Warning #255)
904: /* We moved to the next arg, so move back.
*/
* 905: argv[--i];
906: }
The result of operation '[]' was not used.
"main.c":935, decode_switches(), Result of operator unused (Warning #255)
934: /* We moved to the next arg, so move back.
*/
* 935: argv[--i];
936: }
The result of operation '[]' was not used.
"read.c":393, read_makefile(), Used before set (Warning #290)
392: the default goal before those in the included makefile. */
* 393: record_waiting_files ();
394: read_makefile (p, 2);
#define record_waiting_files() do { record_files (filenames, pattern, pattern_pe
rcent, deps, commands_started, commands, commands_idx, two_colon, filename, line
no, type != 1); filenames = 0; commands_idx = 0; pattern = 0; } while (0)
Automatic variable 'pattern_percent' may be used before set.
Automatic variable 'two_colon' may be used before set.
The conditional expression for 'while' is always false.
---------
During execution, I encountered the following:
"src/make-3.55/read.c":439, read_makefile(), Undefined value (Warning #58)
438:
* 439: record_waiting_files ();
440:
Using auto variable read_makefile`commands_started which has not been set.
Using auto variable read_makefile`two_colon which has not been set.
"/usr/var/tmp/EMP/src/make-3.55/read.c":393, read_makefile(), Undefined value (W
arning #58)
392: the default goal before those in the included makefile. */
* 393: record_waiting_files ();
394: read_makefile (p, 2);
Using auto variable read_makefile`commands_started which has not been set.
Before line 1044 in read.c, "name" is freed. Subsequently, name is
accessed all throughout the routine. Deleting the free call helped,
but I suspect causes a core leak.
At lines 336 and 442 in rule.c, it assigns something to an already-freed
structure; new_pattern_rule() can free it's parameter "r", and the line
following the call blindly uses this freed structure.
new_pattern_rule (r, override);
r->terminal = terminal;
At line 186 in "implicit.c", stemlen turns negative. This would be ok,
except that stemlen is an unsigned integer. It then proceeds to use stemlen
as an index...
That's all for now.
Dave PareC.G.Selwyn%gdr.bath.ac.uk@NSFNET-RELAY.AC.UK (C G Selwyn) (02/07/90)
I have recently installed the GNU make facility on the 4.3BSD system at Perihelion Software and have experienced one (admittedly not very serious) problem. viz. The following makefile which uses a header file which has been found using vpath and then goes on to name the same file but without the vpath searching. This causes make to core dump! vpath %.h tt all: x.o y.o x.o: x.h y.o: tt/x.h The problem appears to be concerned with rename_file where it realises that there is a file with the target name already and proceeds to free it. Unfortunately the freed pointer is then used later when trying to make the file which was named absolutely. I realise that this is not a major bug since one would not want to name files in this way when using vpath but I thought you would be interested nonetheless. Chris Selwyn