In investigating http://bugs.ntp.org/1844 and coming up with a patch to fix NTP and libevent's detection of ld --gc-sections support to work correctly on NetBSD, I tripped over an unexpected difference between AC_LINK_IFELSE and AC_RUN_IFELSE. Briefly, I wanted to change a AC_LINK_IFELSE which grep'ped conftest.err for mention of gc-sections to run the test program as well. My first attempt involved changing AC_LINK_IFELSE to AC_RUN_IFELSE with an extra argument to set the result for cross-compilation. As I eventually discovered, it can be dangerous to (a) rely on autoconf internals and (b) assume AC_RUN_IFELSE is essentially a superset of AC_LINK_IFELSE. At least with Autoconf 2.68 and automake 1.11.1, AC_RUN_IFELSE does not redirect the compile & link command's stderr to conftest.err as AC_LINK_IFELSE does. To achieve what I wanted, I fell back to AC_LINK_IFELSE with m4sh code in the action-if-true to handle the cross-compilation result, or invoke ./conftest manually to examine its exit code. That still leaves me relying on an Autoconf internal, as I couldn't find any documentation of conftest.err usability in action-if-true of AC_LINK_IFELSE. Is there objection to documenting conftest.err availability in action-if-true (or both action-if-true and action-if-false) of AC_LINK_IFELSE? I'm open to a better way to achieve my goal of linking a test program with access to the compile/link stderr, then running it. My preferred better way would be to modify and document AC_RUN_IFELSE to also provide conftest.err to its true and false action snippets. The first pair of links lead to the entire patch I provided for NTP bug 1844, including two variants of the --gc-sections detection fix, one for libevent and one for NTP: http://ntp.bkbits.net:8080/ntp-dev/?PAGE=cset&REV=4d86f00dOJnyJ7aCcBbJ-2kpjBNQPg http://preview.tinyurl.com/1844-entire-patch This pair of links lead to a single copy of the changes I'm referring to: http://ntp.bkbits.net:8080/ntp-dev/sntp/m4/ntp_compiler.m4?PAGE=diffs&REV=4d86f00cI_SngevfRO9XODFzTWPZrA http://preview.tinyurl.com/1844-core-patch I apologize if this would have been better suited to autoconf-patches. Given I have not prepared a patch, I wasn't sure which list was more appropriate. Cheers, Dave Hart _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
