Follow-up Comment #3, sr #110267 (project autoconf): > 'make' is in /usr/ccs/bin on Solaris 11.1 and earlier.
Thanks. I'm sure I used to know that, but I haven't needed to do development on Solaris systems in a long time. Dagobert kindly installed a version of Sun C on gcc210.fsffrance.org that matches the one used for the original bug report: $ /opt/SUNWspro/bin/cc -V cc: Sun C 5.9 SunOS_sparc Patch 124867-16 2010/08/11 I can’t reproduce the exact same failure that was observed for tests 221, 222, or 260, but I *can* reproduce a similar one. The original reported symptoms are: The failure originally reported for 221, 222, and 260 is: ./autotest.at:1938: ${MAKE-make} 0a1,4 > Usage : make [ -f makefile ][ -K statefile ]... [ -d ][ -dd ][ -D ][ -DD ] > [ -e ][ -i ][ -k ][ -n ][ -p ][ -P ][ -q ][ -r ][ -s ][ -S ][ -t ] > [ -u ][ -w ][ -V ][ target... ][ macro=value... ][ "macro +=value"... ] > make: Fatal error: Unknown option `-I' ./autotest.at:1938: exit code was 1, expected 0 I get the same error message if I run /usr/ccs/bin/make -I manually. Both of these tests invoke make with no command line arguments, but if I run the testsuite by hand like this $ MAKEFLAGS=I /bin/bash tests/testsuite -C tests I get the same three failures and many more with the same symptoms. So I’m guessing MAKEFLAGS was somehow set to a nonsense value in the original reporter’s environment. Consistent with this, if I run the testsuite with ‘gmake -j8 check’ I get a closely related error from test 221 and 222 (but not any of the others): ./tests/autotest.at:1929: ${MAKE-make} 0a1,2 > make: Warning: Ignoring DistributedMake -j option > make: Warning: Ignoring DistributedMake -j option Based on this I think we need to isolate the test suite from MAKEFLAGS set by the environment, and conversely we need to arrange for the environment’s value of MAKE to be *honored* consistently (in this case MAKE should have been ‘gmake’ but we got /usr/ccs/bin/make anyway). I’ll work on a patch for that. I cannot reproduce the failure of #307 at all. This is a test of AC_OPENMP. On gcc210.fsffrance.org, /opt/SUNWspro/bin/cc *does* support OpenMP and this is successfully detected: configure:3230: /opt/SUNWspro/bin/cc -D_STDC_C99= -o conftest -xO3 -m32 -xarch=sparc -xopenmp conftest.c >&5 configure:3230: $? = 0 configure:3245: result: -xopenmp But on the machine that was used for the bug report, that option does not work, due to library version skew: configure:3231: /opt/SUNWspro/bin/cc -D_STDC_C99= -o conftest -xO3 -m32 -xarch=sparc -xopenmp -I/opt/csw/include -m32 -xarch=sparc -L/opt/csw/lib conftest.c >&5 ld: fatal: file /lib/libc.so: version 'SUNW_1.23' is unavailable: required by file /lib/libmtsk.so ld: fatal: file /lib/libc.so: version 'SUNW_1.22.7' is unavailable: required by file /lib/libmtsk.so ld: fatal: file processing errors. No output written to conftest AC_OPENMP therefore goes on to try other options, including -openmp, which this compiler will interpret as “write the result of compilation to a file named ‘penmp’.” That invocation fails just like all the others, but a file named ‘penmp’ nonetheless exists in the working directory after configure completes, causing the test to fail. The comments in the definition of AC_OPENMP indicate that this was expected not to happen: dnl If in this loop a compiler is passed an option that it doesn't dnl understand or that it misinterprets, the AC_LINK_IFELSE test dnl will fail (since we know that it failed without the option), dnl therefore the loop will continue searching for an option, and dnl no output file called 'penmp' or 'mp' is created. (There are several other tests of AC_OPENMP but they’re not using all of the AT_CHECK_CONFIGURE machinery and therefore they would not detect this particular failure mode.) I’m not sure what, if anything, to do about this. We probably don’t want to drop ‘-openmp’ from the list of options we try, because (according to the comments) it is the option used for this by Intel’s proprietary compiler, which is IIUC widely used by the sorts of people who write code relying on OpenMP. It’s not safe for AC_OPENMP to delete files named ‘penmp’ and ‘mp’ after the test because they could have existed in the source tree for some other reason--of course, by the same token, AC_OPENMP could clobber such files; we _ought_ to run all compilation tests in a scratch directory but that would be a big, risky change. If this was any piece of software *but* Autoconf I would be OK declaring this particular combination of old compiler and even older C library to be unsupported. But Autoconf is supposed to be robust to things like this. I’d appreciate any ideas you may have. I also observe a failure of test #358 on gcc210.fsffrance.org, due to what appears to be a bug in the system-provided version of gccgo, causing all executables compiled from Go to crash on startup. This shouldn't be counted as an *autoconf* test failure. I will write a patch that makes the Go tests be skipped if the Go compiler can't create runnable executables. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/support/?110267> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/