Today I was looking around for a bug in autoconf, and I noticed one interesting bit out of the NEWS file of the current git version:
Present But Cannot Be Compiled: Autoconf will now proceed with the compiler’s result if a header is present but cannot be compiled. The warning is still printed, and you should really fix it by providing a fourth parameter to AC_CHECK_HEADER/AC_CHECK_HEADERS.
This is a tremendously useful thing to know before autoconf 2.64 is released, which is hopefully not too soon. The reason for this is that finally, after years of having that as a warning, to the point that some projects even ignored it altogether, the new autoconf will start ignoring header files that cannot be compiled, for whatever reason. This is useful since it ensures that headers are not detected that lacks proper dependencies. Unfortunately this also means that any software that currently relies on header files found without compilation will change behaviour. In particular, warnings like the following need to be addressed before the packages get to use autoconf-2.64:
checking bluetooth/bluetooth.h usability... no
checking bluetooth/bluetooth.h presence... yes
configure: WARNING: bluetooth/bluetooth.h: present but cannot be compiled
configure: WARNING: bluetooth/bluetooth.h: check for missing prerequisite headers?
configure: WARNING: bluetooth/bluetooth.h: see the Autoconf documentation
configure: WARNING: bluetooth/bluetooth.h: section "Present But Cannot Be Compiled"
configure: WARNING: bluetooth/bluetooth.h: proceeding with the preprocessor's result
configure: WARNING: bluetooth/bluetooth.h: in the future, the compiler will take precedence
checking for bluetooth/bluetooth.h... yes
Just so you know, this code comes from kdepim-3.5 build, which means that the old KDE build system is once again screwed (it’s very useful to change build system when you can’t even use one properly, the way KDE’s CMake-based build system fails at finding Ruby shows that even without autotools, upstream can make a huge mess, like depending on akonadi to be able to install Umbrello…).
The list of packages having these warnings available is actually not too long which means it should take little time to fix them, the problem is that I think I remember that previously it had a slightly different output message, which means my grep might not have hit properly, I’ll have to investigate that more deeply. Also, these are only the problems identified in Gentoo Linux, I know for sure that there are many more in Gentoo/FreeBSD, since the FreeBSD code does not express all the implicit dependencies between the headers (which is something that I sincerely can’t understand from time to time).
Unfortunately, there is no straight and final recipe to fix these problems, since they can easily be caused b y various entirely different options, for instance it can be a header that is not included when it should be (the most common case, which is what the autoconf news file reported), but it can also be a C99 header included using a compiler set to C89, like in the case above, indeed if you check the config.log file for the above build you’ll see this:
configure:34904: checking bluetooth/bluetooth.h usability
configure:34921: i686-pc-linux-gnu-gcc -c -std=iso9899:1990 -W -Wall -Wchar-subscripts -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -DNDEBUG -O2 -O2 -pipe -Wformat-security -Wmissing-format-attribute -DQT_THREAD_SUPPORT -D_REENTRANT conftest.c >&5
In file included from conftest.c:97:
/usr/include/bluetooth/bluetooth.h:117: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int'
/usr/include/bluetooth/bluetooth.h:121: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void'
And the two lines contain these two definitions:
/usr/include/bluetooth/bluetooth.h:117:static inline int bacmp(const bdaddr_t *ba1, const bdaddr_t *ba2)
/usr/include/bluetooth/bluetooth.h:121:static inline void bacpy(bdaddr_t *dst, const bdaddr_t *src)
The inline keyword is not available in the standard requested by KDE’s build system for the C language, and thus using that header is not correct. But for the sake of finding a solution, it’s very well possible that most KDE packages checking for bluetooth.h could be made not check for it at all (the way KDE build system checks for stuff for single modules in the main configure file is probably one of the most obnoxious mistakes in that abomination).
Now I guess it’s time to start preparing bugs so that we are not unprepared for when this will actually be enacted!
Well, it may be hard to get the upstream to acknowledge this.It was a long time ago, but I remember filing such bug against libXmu, when I sawthis failure during openmotif-2.3.1.1 emerge (regarding X11/Xmu/Editres.h). IIRC, it was rejected as invalid.
Some people think that their header files are correct even if they don’t include their dependencies. Unfortunately there is little one can do but accept it.When that’s the case, though, it has to be corrected in the configure script at least. The @AC_CHECK_HEADERS@ macro has a parameter that allows to include further header files if needed.