[sr #110353] AC_OPENMP leaves a file named "penmp" in the srcdir with Sun C 5.9

[Zack Weinberg]

URL:
  <https://savannah.gnu.org/support/?110353>

                 Summary: AC_OPENMP leaves a file named "penmp" in the srcdir
with Sun C 5.9
                 Project: Autoconf
            Submitted by: zackw
            Submitted on: Sat 31 Oct 2020 03:01:04 PM UTC
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: Confirmed
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None

    _______________________________________________________

Details:

Test 313 (AC_OPENMP) can fail with Sun C 5.9 by leaving a file named "penmp"
in configure's working directory.

This compiler actually does support OpenMP, but with the right combination of
operating system patches applied and not applied, the option that should
enable support doesn't work, you get a link failure:


configure:3238: /opt/SUNWspro/bin/cc -D_STDC_C99= -o conftest -xO3 -m32
-xarch=pentium_pro -xchip=pentium_pro -xopenmp -I/opt/csw/include -m32
-xarch=pentium_pro -xchip=pentium_pro -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


This makes AC_OPENMP continue trying to find options that will work, one of
which is


configure:3238: /opt/SUNWspro/bin/cc -D_STDC_C99= -o conftest -xO3 -m32
-xarch=pentium_pro -xchip=pentium_pro -Popenmp -I/opt/csw/include -m32
-xarch=pentium_pro -xchip=pentium_pro -L/opt/csw/lib conftest.c  >&5
configure:3238: $? = 0


The `-Popenmp` option is interpreted as `-P -o penmp`, i.e. create a file
named 'penmp' which contains the result of _preprocessing_ conftest.c.  Note
that this invocation _succeeds_, but the AC_LINK_IFELSE that ran it fails
anyway, because it did not create conftest$ac_exeext.

The author of AC_OPENMP anticipated this problem:


          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.


but apparently did not consider the possibility of an AC_LINK_IFELSE failing
but creating 'penmp' nonetheless.

A fix for this exact situation would be to run a compile test for each option
first.  That would detect that `-xopenmp` is the correct option to use for
this compiler, and then we would do a link test with that option to verify
that it actually works, determine that it doesn't, and proceed to report
"unsupported" without ever trying `-Popenmp`.  However, the fundamental
problem remains; compile tests could also wind up creating a file named
'penmp' or 'mp'.

Ideally, we would run all tests that can create files in a scratch directory,
not in the top level of the source or build tree.  That's much too big of a
change for 2.70, though, and may not be possible at all.  The only other thing
I can think of is to have AC_OPENMP check before its main loop that no files
named 'penmp' or 'mp' exist.  If they do, it aborts, because the problem
compiler invocations would clobber those files.  If they don't, though, then
it can safely delete them afterward.

Does anyone have a better idea?

(Originally reported by Dagobert as part of sr #110320, logs extracted from
file #49872.)




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/support/?110353>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/