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

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. — Yann, Aug 26 '11 at 16:11
@Yann: That is not happening for me. On MacOSX I see this behavior, but on Ubuntu I do not. — paleozogt, Aug 26 '11 at 16:12
@Yann: I've edit the question to show a sample of my config.log — paleozogt, Aug 26 '11 at 16:24
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? — Yann, Aug 26 '11 at 16:51
@Yann: This is why I need to know what the test code is from the log and/or get at the temp files. — paleozogt, Aug 26 '11 at 16:58
@paleozogt let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/2900/discussion-between-yann-and-paleozogt) — Yann, Aug 26 '11 at 17:03
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? — William Pursell, Aug 31 '11 at 09:32

score 12 · Accepted Answer · edited Sep 02 '20 at 17:53

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.

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 — andreabedini, Aug 25 '12 at 06:00

score 2 · Answer 2 · answered Oct 20 '21 at 02:34

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 "bug-hello@gnu.org"
| #define PACKAGE_URL "http://www.gnu.org/software/hello/"
| #define PACKAGE "hello"
| #define VERSION "2.10"
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }

autotools temporary files

2 Answers2