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

[Dagobert Michelsen]

Hi Zack,

Am 05.08.2020 um 16:42 schrieb Zack Weinberg <INVALID.NOREPLY@gnu.org>:
> 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

This error usually happens when e.g. GNU make is explicitly called on the
first invocation and then another make is called from inside the Makefile with
„make $(MAKEFLAGS)“ resulting in „make“ to be searched from PATH instead of
using the make of the original invocation. This should have been „$(MAKE) 
$(MAKEFLAGS)“
instead. I don’t know if it really happened this way, but often this kind of
error is triggered by that cause.

> $ 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.

Yes, this is definitely a good idea.

> 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

Ahhh, I tested from inside my packaging environment and we explicitly
restrict the used libc version here to be compatible with older versions
of Solaris too. This fails when recent libraries explicitly demand the
newer set of functions only available in the newer interface contracts.
This is totally my fault, sorry. The correct solution for me is to either
not use openmp when restricting libc version or not restricting and
hence limit to newest libc patch revisions only.

> 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.

These are probably artifacts of my specific environment. Some go programs
unfortunately result in crashing binaries due to a bug in GCC which I never
have really gotten around to isolate. I guess this also can be safely ignored.

I am really sorry for producing so much self-induced noise instead of taking
a look myself first :-/


Best regads

  — Dago