Question

I’m trying to debug an autotools problem for an open-source project, which is failing at the configure step. I’d like to see the code/executable that configure is trying to run.

However, the config.log only shows that something failed (not the code it tried to compile) and I don’t know where the temporary executables are being stored (and they’re probably promptly deleted anyway).

Is there a way get autotools to keep its temporary files around? It doesn’t matter at which level this is specified– either with args to configure, args to autoconf when it generates configure, or even some m4 invocation.

EDIT When something fails, configure.log looks like this:

configure:3285: checking whether we are cross compiling
configure:3293: gcc -o conftest.exe -DU_STATIC_IMPLEMENTATION -O3   conftest.c  >&5
configure:3297: $? = 0
configure:3304: ./conftest
configure:3308: $? = 1
configure:3315: error: in `/home/bobthebuilder/Development/icu/build':
configure:3317: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

Answer 1

This is a complete hack, but it works. You can edit the configure script; specifically, you can edit the subroutine ac_fn_c_try_compile (). Search for this line in the configure script, then edit it by adding these lines right after the initial declaration of ac_fn_c_try_compile:

ac_fn_c_try_compile ()
{
  echo "=================== " >> config.log
  echo "conftest.$ac_ext is " >> config.log
  cat conftest.$ac_ext >> config.log 
  echo "=================== " >> config.log

This will force conftest.$ac_ext (ie conftest.c) to be printed to the config.log file, every time. Keep in mind, each time you rerun autoconf (if you are doing this) or autoreconf, this custom configure script is overwritten. There is probably a way to hijack the definition of ac_fn_c_try_compile.