helpAutoconf - Support: sr #110267, Testsuite regressions from 2.69 on...

 
 

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

Submitter:  Zack Weinberg <zackw>
Submitted:  Wed 15 Jul 2020 12:16:19 AM UTC
 
Category:  None Priority:  1 - Later
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Operating System:  Solaris
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Mon 30 Nov 2020 08:32:28 PM UTC, comment #6: 

I was finally able to reproduce the 'penmp' bug myself, and it's fixed in f1047b2e9656ba1cb3b672df22b2178ad0b38738.  The only remaining failure in the testsuite for me on Solaris 10 and 11 is the intermittent failure of test 209 which is being tracked in issue #110354.  Closing this bug report.

Zack Weinberg <zackw>
Project Administrator
Thu 24 Sep 2020 08:45:36 PM UTC, comment #5: 

The Make-related failures were fixed in c42dd55ddd598b45664899bfc171c13945a77c0c and 1a5ed4566952f5b2ad854939357ff4b6ec2de180 .

I believe the only remaining problem is with OpenMP detection sometimes leaving a file named `penmp` in the build directory.  That's a shouldn't-ever-happen condition that I can't make happen myself; without a reliable way to reproduce it I'm not going to be able to do anything about it.  I'm going to leave this bug open for now but mark it "need info" and "later".

Zack Weinberg <zackw>
Project Administrator
Tue 18 Aug 2020 08:56:14 PM UTC, comment #4: 

The spurious failure due to a broken Go compiler is fixed in fa0754f704d7442cb2780d740fa4aabe2ba19f86.

Zack Weinberg <zackw>
Project Administrator
Wed 05 Aug 2020 02:42:25 PM UTC, comment #3: 

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

Zack Weinberg <zackw>
Project Administrator
Fri 17 Jul 2020 08:16:30 AM UTC, comment #2: 

> neither /opt/SUNWspro/bin/cc nor any command named `make` is installed.

'make' is in /usr/ccs/bin on Solaris 11.1 and earlier.

I just tried 'make check' on Solaris 10 sparc and it worked for me. 501 tests behaved as expected (of which 4 were expected failures: 28 31 32 33), and 22 tests were skipped (36 37 40 89 260 264 265 266 268 269 274 275 288 289 330 351 352 353 354 357 358 521).

This was on a Sun Fire 280R (UltraSPARC-III, circa 2001) running Solaris 10 non-virtualized. It's still in production use and was most recently brought up-to-date in Solaris patches on July 10. I ran the current autoconf master (commit c03ca42de310c5647b7970ae1bbb1344977cb384) on it, with PATH set to '/home/eggert/junk/bin:/usr/bin:/usr/perl5/bin:/usr/ccs/bin:/opt/SUNWspro/bin', where /home/eggert/junk/bin contains only m4 (a privately-installed version of GNU m4 1.4.16, as the system-supplied /usr/sfw/bin/gm4 is 1.4.2 which is too old for today's Autoconf) and /opt/SUNWspro/bin/cc is Sun C 5.9 Patch 124867-12 2009/11/22.

If it's not working on other Solaris platforms despite the recent Autoconf patches, we can compare the other platforms' configuration to the one above to see whether we can narrow down the cause of the problem.

Paul Eggert <eggert>
Project Administrator
Thu 16 Jul 2020 09:10:10 PM UTC, comment #1: 

I've pushed a partial fix for this.  As of revision 71b5037a, tests 365 367 390 391 392 393 394 395 396 397 398 399 400 should pass.

209 appears to be an intermittent race condition in the parallel testsuite driver, not Solaris-specific; I will look into it further but it only causes cosmetic problems (the test fails because it's checking the cosmetics of testsuite output).

The remaining failures (221 222 260 307) all appear to be problems either with Sun's compilers or Sun's `make`, and I can't reproduce these on the only Solaris 10 host I have access to (gcc210.fsffrance.org, aka gcc-solaris10.baltic-online.de) because neither /opt/SUNWspro/bin/cc nor any command named `make` is installed.  (The problems do not reproduce with /opt/solstudio12.2/bin/cc and /opt/solstudio12.2/bin/dmake.)  Would you mind digging into these a little deeper?  I think the `make`-related failures at least should be easy (something is setting MAKEFLAGS to a garbage value?)

Zack Weinberg <zackw>
Project Administrator
Wed 15 Jul 2020 12:16:19 AM UTC, original submission:  

From Dagobert Michelsen <dagobert at familie-michelsen dot de>:

> I have quite a number of failing tests on Solaris 10 Sparc:
>
>  testsuite: 209 221 222 260 307 365 367 390 391 392 393 394 395 396 397 398 399 400 failed
>
> Please see the compressed archive with the specific test results

attached

Zack Weinberg <zackw>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #49484:  testsuite.dir.tar.bz2 added by zackw (1MiB - application/x-bzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by eggert (Posted a comment)
  • -email is unavailable- added by zackw (Submitted the item)
  • -email is unavailable- added by zackw
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

     

     

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-30 zackw StatusNeed Info Done
        Open/ClosedOpen Closed
    2020-09-24 zackw Priority5 - Normal 1 - Later
        StatusIn Progress Need Info
    2020-08-05 zackw StatusWorks For Me In Progress
    2020-07-17 eggert StatusNone Works For Me
    2020-07-15 zackw Attached File- Added testsuite.dir.tar.bz2, #49484
        Carbon-Copy- Added -email is unavailable-

    Back to the top


    Powered by Savane 3.9