-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [adding bug-automake; this is http://thread.gmane.org/gmane.comp.gnu.m4.bugs/2388]
According to Chan, Lawson on 1/30/2008 12:46 PM: | Hi Eric, | | Thanks for your reply. I am sorry that I have difficulties in removing the disclaimer because it is out of my control. Nothing prevents you from using a free webmail account, or finding a newsreader gateway that won't add a disclaimer (I personally like gmane). | I am running the make in both shell (bash or Korn) and they have exactly the same behaviour. It doesn't matter what shell you ran make from; what mattered is what shell make was running as it spawned commands. What does 'env | grep SHELL' say? Your log shows that you are running bash 2.03, which is rather old, but I don't think that's an issue. I personally know that M4 builds just fine on Solaris 8, so it is something about your environment that caused your failure, and not a flaw in the M4 package. | | /M4/m4-1.4.10/checks | bash: fail: unbound variable | *** Error code 1 | make: Fatal error: Command failed for target 'all-recursive' | | Here is the attached configure and make output file for your reference. You still didn't show me the command lines that you typed. | | Yes, the ./configure is successfully executed. Any thought about this? It looks like an automake issue to me. It looks like you have somehow enabled the 'set -u' option of bash. Looking at what automake outputs for $(RECURSIVE_TARGETS) in each Makefile, I see: $(RECURSIVE_TARGETS): ~ @failcom='exit 1'; \ ~ for f in x $$MAKEFLAGS; do \ ~ case $$f in \ ~ *=* | --[!k]*);; \ ~ *k*) failcom='fail=yes';; \ ... ~ || eval $$failcom; \ ~ done; \ ~ if test "$$dot_seen" = "no"; then \ ~ $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \ ~ fi; test -z "$$fail" In other words, if you did NOT use 'make -k', then eval $$failcom never initialized $fail, and test -z "$$fail" ends up expanding an undefined $fail, explaining the bash warning. I've never seen a make implementation use 'set -u' (although I do know that some make use an implicit 'set -e'), and since POSIX requires make to ignore $SHELL from the environment, I'm not quite sure whether the user had a posix-compliant setup to begin with. ~ Then again, POSIX states that it is not portable to assign SHELL within a makefile, while autoconf recommends doing exactly that via [EMAIL PROTECTED]@, and 'set -u' _is_ posix-compliant. So should automake cater to this weird SHELL setting by doing failcom='fail=; exit 1' as the default value for $failcom (and audit for any other potentially unset variables)? Or is it better to figure out how this user got 'set -u' enabled in your SHELL in the first place, and add workarounds (perhaps in autoconf, rather than automake?) to avoid such an awkward setup? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHoNjV84KuGfSFAYARAj2lAJoCjxFaHdSDoREq7AHBJg+EGzniCQCeK4TL VcOy9V5e618/oxh/ZycO59Q= =neTy -----END PGP SIGNATURE-----
