Stefano Lattarini [off-list ref] writes:
On a Solaris 10 system with Solaris XPG4 make installed as /usr/xpg4/bin/make,
GNU make installed as /usr/local/bin/make, and with /usr/local/bin appearing
in $PATH *before* /usr/xpg4/bin, I was seeing errors like this upon invoking
"make all":
After reading this explanation, my first reaction is that the prefixing of
path _is_ what is wrong. The prefixing is done to help a subset of
Solaris users who are unaware of /usr/xpg4/bin that are more POSIX than
what they have in /usr/bin, and that is what is hurting people like you
who know what you are doing and have suitable tools in other places, like
you do in /usr/local/bin.
And the real fix for your problem is _not_ an ugly override of $(MAKE)
like you do in this patch, I think. After all, somebody else who have a
tool in /usr/local/bin that is saner than what is in /usr/xpg4/bin may
suffer from the same issue for commands other than "make".
So the real solution would probably be to let you override how the
BROKEN_PATH_FIX works, no?
Ah... and I think we already have such a solution in our Makefile. Can't
you override SANE_TOOL_PATH in your config.mak instead?
+# This Makefile will possibly sanitize PATH by prepending system-specific
+# directories to it (e.g., /usr/xpg4/bin on Solaris). This can become
+# problematic for recursive make invocations, if one of those directories
+# contains a "make" program and the user has called GNU make by simply
+# invoking "make" (this can happen e.g. when GNU make has been installed
+# as /usr/local/bin/make). To avoid such issues, we redefine $(MAKE) to
+# point to the absolute path of the originally-invoked make program.
+# FIXME: this is ugly, and which(1) is quite unportable. Find a better
+# way to obtain the same effect.
+MAKE := $(shell set $(MAKE); m1=$$1; shift; \
+ m2=`which $$m1 2>/dev/null` && test -n "$$m2" || m2=$$m1; \
+ echo "$$m2 $$*")
+
# CFLAGS and LDFLAGS are for the users to override from the command line.
CFLAGS = -g -O2 -Wall