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 > [yuri@yv /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. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
