bug-autoconf
[Top][All Lists]
Advanced

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

[sr #110267] Testsuite regressions from 2.69 on Solaris 10 (SPARC)


From: Zack Weinberg
Subject: [sr #110267] Testsuite regressions from 2.69 on Solaris 10 (SPARC)
Date: Wed, 5 Aug 2020 10:42:25 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

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/




reply via email to

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