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/
