bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gmake-4.2.1 ignores assignment of ARCH on FreeBSD


From: Paul Smith
Subject: Re: gmake-4.2.1 ignores assignment of ARCH on FreeBSD
Date: Tue, 26 Dec 2017 16:59:41 -0500

On Tue, 2017-12-26 at 13:38 -0800, Yuri wrote:
> On 12/26/17 13:29, Paul Smith wrote:
> > Well, this clearly shows that the ARCH variable has been supplied
> > on the command line, NOT through the environment.
> 
> Except, it was not!

It was... somehow.

> When I stop the make process, and look at its info under /proc, ARCH
> is certainly not in the supplied arguments:
> 
> $ ps ax | grep gmake
> 11802  4  T       0:00.01 gmake -f Makefile -j8 CC=cc LINKCC=cc
> DCC=cc LDFLAGS= -fstack-protector -L/usr/local/lib -lgmp -lm -lz
> SHARED=true all
> 11879  4  S+      0:00.00 grep gmake
> address@hidden /usr/ports/math/zimpl]$ cat /proc/11802/cmdline
> gmake -f Makefile -j8 CC=cc LINKCC=cc DCC=cc LDFLAGS= -fstack-
> protector -L/usr/local/lib -lgmp -lm -lzSHARED=true all

This means is that it wasn't supplied on the command line to THIS
instance of make.

Makefiles are often written recursively, which means one makefile will
invoke make again, for example in a subdirectory or with a different
set of arguments.

Any variable assignments provided on the command line to the top level
make invocation (or indeed, any intermediate make invocation) are
preserved and passed down as if they were command-line variable
assignments to sub-makes as well. However, this is not done by
modifying the actual command line that make invokes: instead it's
provided through special make-internal settings in the environment.

So if you have a makefile like:

  $ cat Makefile
  all: ; $(MAKE) recurse

  recurse: ; @echo $(ARCH)

and you invoke "make ARCH=foo" you'll have the expected value printed
out, even though you won't see ARCH=foo on the command line of the
recursive make invocation.

So while this particular instance of "gmake" may not have that variable
assigned, some parent "gmake", which then invoked this "gmake", did
have it assigned on the command line. Along with the values of
_SMP_CPU, _PKG_CHECKED, _PERL5_FROM_BIN, _OSRELEASE, OSVERSION, etc. as
can be seen in this value:

> -*-command-variables-*- := SHARED=true LDFLAGS=-fstack-protector\ 
> -L/usr/local/lib\ -lgmp\ -lm\ -lz DCC=cc LINKCC=cc CC=cc _SMP_CPUS=8 
> _PKG_CHECKED=1 _PERL5_FROM_BIN=5.24.3 _OSRELEASE=11.1-STABLE 
> OSVERSION=1101506 OSREL=11.1 OPSYS=FreeBSD
> HAVE_COMPAT_IA32_KERN=YES\  
> ARCH=amd64

You need to find the parent PID of that gmake command and see who calls
it, and investigate that.

Under normal circumstances this value is managed (created, read,
modified) only by GNU make.  I suppose it's possible that the ports
system on FreeBSD plays some trickery here (assigning these internal
variables directly) but I wouldn't know about that.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]