title: More robust AC_COMPILE_IFELSE feature testing?
body: <p>Autoconf's <code>AC_COMPILE_IFELSE</code> is misdetecting features for us under different compilers, like Sun's C++ compiler and IBM's xlC compiler. <code>AC_COMPILE_IFELSE</code> 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.</p>
  
  <p>In my non-Autoconf build scripts I use <code>"fatal|error|illegal|unrecognized|not found|not exist"</code> to detect a compiler or linker complaint. It is more robust than just checking <code>$?</code>. The test looks like:</p>
  
  <pre><code># infile and outfile are temp files that allow testing a feature
  SH_ERROR=$($CXX -Wl,--enable-new-dtags -o "$outfile" "$infile" 2&gt;&amp;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
  </code></pre>
  
  <p>The Autoconf documentation for <code>AC_COMPILE_IFELSE</code> is at <a href="https://www.gnu.org/software/autoconf/manual/autoconf-2.66/html_node/Running-the-Compiler.html" rel="noreferrer">6.4 Running the Compiler</a>, but it does not discuss the subject matter. In fact, the document does not even define what it means for <code>AC_COMPILE_IFELSE</code> to be "success[ful]".</p>
  
  <p>My first question is, are compiler return values standardized somewhere?</p>
  
  <p>My second question is, what does Autoconf use to determine "success"?</p>
  
  <p>My third question is, how do we do the same in Autoconf? Is there something else to use besides <code>AC_COMPILE_IFELSE</code>?</p>
  
  <p>A related question is (based on Stefan's answer), how do we get Autoconf to use an improved <code>AC_COMPILE_IFELSE</code>? Is it possible to undef the current <code>AC_COMPILE_IFELSE</code> and define it to the more robust version?</p>
  
  <p>Thanks in advance.</p>