autotools temporary files

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

Flathead

When a test fails for configure, config.log prints out the program and compilation command used to make the program. This is the case for me at least. I get 'configure: failed program was:' lines right before the program is printed out. – Boondocks

@Yann: That is not happening for me. On MacOSX I see this behavior, but on Ubuntu I do not. – Flathead

What does config.log report when a test fails? – Boondocks

@Yann: I've edit the question to show a sample of my config.log – Flathead

My guess is that your gcc compiler or the corresponding standard libraries are in correctly installed. What's the corresponding configure.ac line that leads to this issue? – Boondocks

@Yann: This is why I need to know what the test code is from the log and/or get at the temp files. – Flathead

@Flathead let us continue this discussion in chat – Boondocks

Configure is building conftest.ext and then trying to run conftest. It looks like you are not doing a windows build, however. Is EXEEXT getting set somewhere? – Hosanna

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.

Boondocks

nice trick! I would rather suggest something on the lines of: $as_echo "$as_me: the test program is:" >&5 sed 's/^/| /' conftest.$ac_ext >&5 – Clone

Answer 2

As of Autoconf 2.71, this is already done automatically. Search the config.log file for the string "configure: failed program was:"; the listing of the failed test program is shown in full following that line, e.g.:

configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU Hello"
| #define PACKAGE_TARNAME "hello"
| #define PACKAGE_VERSION "2.10"
| #define PACKAGE_STRING "GNU Hello 2.10"
| #define PACKAGE_BUGREPORT "[email protected]"
| #define PACKAGE_URL "http://www.gnu.org/software/hello/"
| #define PACKAGE "hello"
| #define VERSION "2.10"
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }

Zaccaria