Why doesn't autoconf pass the AC_CHECK_HEADER test when the .h is file clearly available?

Question

I am having a bear of a time getting autoconf to check for the presence of a particular header file.

Let's call the header dependency "inky.h", and let's say that inky is a library that was installed (seperately) with the prefix set to "/usr/local". This put "inky.h" in /usr/local/inky/inky.h and libinky.so in /usr/local/lib.

Now, I'm trying to verify the presence of inky.h in my applications configure.ac as follows:

dnl # Setup temp LDFLAGS and look for inky library/header
LDFLAGS_SAVE=${LDFLAGS};
CPPFLAGS_SAVE=${CPPFLAGS};

dnl # Look for inky on the user specified inky install path
LDFLAGS ="-L${inky_library_path}";
CPPFLAGS="-I${inky_include_path}/inky";

AC_MSG_NOTICE([Looking for inky.h using: ${CPPFLAGS}]);

dnl # This check finds inky.h just fine.  This check was only used for debugging
AC_CHECK_FILE(
   [${inky_include_path}/inky/inky.h],
   [AC_MSG_NOTICE([Found inky.h])],
   [AC_MSG_NOTICE([Didn't find inky.h])]
   )

dnl # Look for the inky header file.  If it isn't found, terminate.
AC_CHECK_HEADER(inky.h,
    [],
    [AC_MSG_ERROR([Couldn't find or include inky.h])]
    )

This produces the following output from ./configure (after an autoreconf -vfi):

configure: Looking for inky.y in fetk include path: -I/usr/local/include/inky.y
checking for /usr/local/include/inky/inky.h... yes
configure: Found inky.h
checking inky.h usability... no
checking inky.h presence... yes
configure: WARNING: inky.h: present but cannot be compiled
configure: WARNING: inky.h:     check for missing prerequisite headers?
configure: WARNING: inky.h: see the Autoconf documentation
configure: WARNING: inky.h:     section "Present But Cannot Be Compiled"
configure: WARNING: inky.h: proceeding with the compiler's result
checking for inky.h... no
configure: error: Couldn't find or include inky.h

Now, this appears to be the case because inky.h includes 2 other headers, so I add them in on the fourth parameter of AC_CHECK_HEADER like so:

dnl # Look for the inky header file.  If it isn't found, terminate.
AC_CHECK_HEADER(inky.h,
    [],
    [AC_MSG_ERROR([Couldn't find or include inky.h])],
    [dinky.h plinky.h]
    )

Which renders this output from ./configure:

configure: Looking for inky in fetk include path: -I/usr/local/include/inky
checking for /usr/local/include/inky/inky.h... yes
configure: Found inky.h
checking for inky.h... no
configure: error: Couldn't find or include inky.h

I'm at my wits end with autoconf. Does anyone have any idea where I'm going wrong here. Is it possible to get configure to provide more details about what is failing? Why can I find the file itself, but the AC_CHECK_HEADER macro fails?

Also, please don' tell me to use a different package distribution suite. I would never have chosen Autoconf myself, but I do have to add some dependencies to a pre-existing project.

Also note that the actual library is not named "inky." However, there is an issue of "official use only" for this project, so I have changed the names to protect the...well, to protect myself!

[Edit - Closing] Figured out the problem. See my answer.

Aureus

This is probably just a typo, but you cannot put a space between LDFLAGS and ="..." (unless you want to run the program LDFALGS with ="..." as first argument. – Motivity

Thank you. I actually caught that error a few minutes ago, but you are certainly right. One of the things that I absolutely hate about Autoconf is the rigidity of the spacing rules. – Aureus

Answer 1

I found what the issue was. The library that I am working with is a C library, but the "inky" library that I am linking against is a C++ library. So, the language (AC_LANG) was set to C early in the configure.ac script. While performing checks for "inky", I needed to change the language to C++ so that Autoconf used the C++ compiler instead of the C compiler. This was done rather easily by using:

AC_LANG_PUSH([C++])
dnl # Do the checks for inky
AC_LANG_POP([C++])

This solved both the problem that I asked about in this thread, and on that I hand't posted yet wherein I couldn't get the AC_CHECK_LIB macro to work.

Thank you everyone for your input.

Aureus

Answer 2

The fourth argument of AC_CHECK_HEADER is not a list of headers, but some C code that performs the include.

Maybe try something along the line of

AC_CHECK_HEADER([inky.h],
[],
[AC_MSG_ERROR([Couldn't find or include inky.h])],
[#include <dinky.h>
#include <plinky.h>
])

or even

AC_CHECK_HEADERS([dinky.h plinky.h inky.h],
[],
[AC_MSG_ERROR([Couldn't find or include this header])],
[#if HAVE_DINKY_H
#  include <dinky.h>
#endif
#if HAVE_PLINKY_H
#  include <plinky.h>
#endif
])

Motivity

Thanks. You are right about that 4th argument. I tried that, but unfortunately it didn't solve the problem. – Aureus

Answer 3

The details about why this test is failing are in config.log. My guess is though, that:

• Since you're not adding the path found with AC_CHECK_FILE to CPPFLAGS or INCLUDES or whatever autoconf is using these days.
• AC_CHECK_HEADER does not find the header using preprocessor compilation (for another reason than the header being missing in CPPFLAGS includes).

Ignoramus

It makes sense as one sentence as well. Add an "or" and keep the list? – Philosophical

@KarlRichter I've read this passage about 10 more times. Now it looks as a single and complete sentence. Sorry for confusing, you seem to have been right in the firt edit. – Insufferable

Me too :) I think that the new version (which is to be reviewed) reuses the second half of the sentence (previously the second list item) to clarify that there might be other reasons. WFM – Philosophical