Autoconf's AC_COMPILE_IFELSE
is misdetecting features for us under different compilers, like Sun's C++ compiler and IBM's xlC compiler. AC_COMPILE_IFELSE
appears to check return values, but some compilers don't bother to set it or set it to unexpected values. Later, we use options that are not available.
In my non-Autoconf build scripts I use "fatal|error|illegal|unrecognized|not found|not exist"
to detect a compiler or linker complaint. It is more robust than just checking $?
. The test looks like:
# infile and outfile are temp files that allow testing a feature
SH_ERROR=$($CXX -Wl,--enable-new-dtags -o "$outfile" "$infile" 2>&1 | $EGREP -i -c -E 'fatal|error|illegal|unrecognized|not found|not exist')
if [[ "$SH_ERROR" -eq "0" ]]; then
CXXFLAGS+="-Wl,--enable-new-dtags"
fi
The Autoconf documentation for AC_COMPILE_IFELSE
is at 6.4 Running the Compiler, but it does not discuss the subject matter. In fact, the document does not even define what it means for AC_COMPILE_IFELSE
to be "success[ful]".
My first question is, are compiler return values standardized somewhere?
My second question is, what does Autoconf use to determine "success"?
My third question is, how do we do the same in Autoconf? Is there something else to use besides AC_COMPILE_IFELSE
?
A related question is (based on Stefan's answer), how do we get Autoconf to use an improved AC_COMPILE_IFELSE
? Is it possible to undef the current AC_COMPILE_IFELSE
and define it to the more robust version?
Thanks in advance.
std::cout << "A-128-bits-GUID\n"
, and the test should only pass if there's an executable generated which echoes back that string. Of course, that is a slight challenge for cross-compiles. – MSalters