[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_CHECK_HEADER question

From: Jan van Dijk
Subject: Re: AC_CHECK_HEADER question
Date: Mon, 18 Mar 2013 09:50:18 +0100
User-agent: KMail/1.13.6 (Linux/; KDE/4.6.0; x86_64; ; )

On Monday 18 Mar 2013 01:05:59 Zack Weinberg wrote:
> On Sun, Mar 17, 2013 at 5:35 PM, Jan van Dijk <address@hidden> 
> > That is a bit disappointing, though: it generates a lot of extra work for
> > the author, only to find out what autoconf already knows:
> > where it could find a particular header file. It will also make the
> > scripts less robust.
> Thing is, Autoconf *doesn't* know where the header is.  When you do
> AC_CHECK_HEADER([superlu/slu_util.h])
> that gets translated to something along the lines of
> printf '#include <%s>\n' 'superlu/slu_util.h' > conftest.c
> if $CC $CFLAGS $CPPFLAGS -c -o conftest.o conftest.c >>config.log 2>&1
> then
>   action-if-found
> else
>   action-if-not-found
> fi
> So it's the *C compiler* that searches for the header file, and it
> doesn't tell the configure script where it found it.

Dear Zack,

I guess my confusion stems from the fact that autoconf claims to check for 
presence and usability separately. Indeed, I just found out that 'presence' 
rather means that the file can be preprocessed. I did:


where foo.h contains:

#error I do not exist

To my surprise, configure tells me that foo.h does not exist, before pointing 
out that it is usable neither. Is that a documentation glitch?

Would it be possible to provide a new macro AC_WHICH_HEADER, say, which 
informs it user what header has been/will be picked up by the preprocessor? 
Perhaps it could use the compiler's dependency tracking system, as in:

echo "#include <math.h>" | gcc -E -M - | head -n1 | cut -f 3 -d ' '

I have no idea if this can be expressed in a sufficiently portable way that 
would allow its inclusion in autoconf.
> You could do something like this instead:

Thank you very much for that insightful suggestion.

With kind regards,

jan van Dijk.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]