Clinton Roy wrote:
Hey folks,
I'm looking for an ndbm header file, Solaris has <ndbm.h>, Redhat uses <gdbm/ndbm.h> and Debian has <gdbm-ndbm.h>, so the call to AC_CHECK_HEADERS is:
AC_CHECK_HEADERS(ndbm.h gdbm/ndbm.h gdbm-ndbm.h)
However, the generated configure script seems to think gdbm/ndbm.h and gdbm-ndbm.h are the same:
checking ndbm.h usability... no checking ndbm.h presence... no checking for ndbm.h... no checking gdbm/ndbm.h usability... no checking gdbm/ndbm.h presence... no checking for gdbm/ndbm.h... no checking for gdbm-ndbm.h... (cached) no
Is there anything I'm missing?
wwwoooowww, cunning. Quick answer: your way of using the macro is quite right but autoconf can not handle this kind of thing. And probably it can not do that (ever) so you have to start using some kind of workaround.
background: The result of each test is memorized in a "cache". Since we are in plain shell that "cache" is not an object or special container or something, it fact the term is rather virtual, and such an object does not exist. Instead, autoconf will flatten the test strings gdbm/ndbm.h and gdbm-ndbm.h to a symbol that can be used as a shell variable, and also prepend a prefix that say "this is a cache variable". In effect, we see:
------- test call -------- ------ cache variable used ------
AC_CHECK_HEADER(ndbm.h) ac_cv_header_ndbm_h=${result}
AC_CHECK_HEADER(gdbm/ndbm.h) ac_cv_header_gdbm_ndbm_h=${result}
AC_CHECK_HEADER(gdbm-ndbm.h) ac_cv_header_gdbm_ndbm_h=${result}see? and if you put these out to a config.h.in it would be
/* Define to 1 if you have the <ndbm.h> header file */ #undef HAVE_NDBM_H
/* Define to 1 if you have the <gdbm/ndbm.h> header file */ #undef HAVE_GDBM_NDBM_H
/* Define to 1 if you have the <gdbm-ndbm.h> header file */ #undef HAVE_GDBM_NDBM_H
see? You can not make use of that in your programs simply because all the test strings do need to be changed over into a symbol - both for usage inside the `configure` script itself and for usage inside your program sources via `config.h`
Solutions? Before starting out an anything, send a message to the redhat and debian maintainers of that package and inform them of the situation. I repeat, send a message - autoconf testing is very very important for gnuish software, so they _will_ listen. And if they don't, come back and we'll get out the big guns - this situation is not acceptable, stop.
If you want to start hacking now, you have to deploy a nasty workaround. Check the definition of AC_CHECK_HEADER (without the final "S"). It has an ACTION-IF-FOUND and ACTION-IF-NOT-FOUND part. Therefore,
AC_CACHE_CHECK(for redhat gdbm/ndbm.h,ac_cv_header_redhat_gdbm_ndbm_h,[ unset ac_cv_header_gdbm_ndbm_h AC_CHECK_HEADER(gdbm/ndbm.h, ac_cv_header_redhat_gdbm_ndbm_h="$ac_cv_header_gdbm_ndbm_h" AC_DEFINE_UNQUOTED(AS_TR_CPP(HAVE_REDHAT_GDBM_NDBM_H 1)) ])
AC_CACHE_CHECK(for debian gdbm-ndbm.h,ac_cv_header_debian_gdbm_ndbm_h,[ unset ac_cv_header_gdbm_ndbm_h AC_CHECK_HEADER(gdbm-ndbm.h, ac_cv_header_debian_gdbm_ndbm_h="$ac_cv_header_gdbm_ndbm_h" AC_DEFINE_UNQUOTED(AS_TR_CPP(HAVE_DEBIAN_GDBM_NDBM_H 1)) ])
warning: the code above is not tested, I've just written it up from memory. It is a demonstration how such an ugly hack would be done. Again, contact the debian and redhat maintainers, and tell them. This mail is more for giving you a chance to refer them to a point explaining the technical heart of the problem. (or otherwise we would need to memorize this ugly mess in its own ac-macro and ship it around - and I do _not_ want that)
good luck, -- guido http://AC-Archive.sf.net GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X-
