Followup on autoconf 2.62 problems

I wrote about autoconf 2.62 problems as soon as I found one, and I did expect more to come. As it happens, I wasn’t that wrong, and while the tracker is still filling up, problems arose. Some of which didn’t even pass through bugzilla – if a package of mine fails, I tend to fix it without documenting it in the Bugzilla, I know it’s wrong, I probably should, for reference.

For those who are interested in the problems that can arise with autoconf 2.62, I can list a few:

• variable names are validated, which means that variables like FONTCONFIG-LIBS will make autoconf fail; note that this was an error before, too, it just wasn’t caught, the results of it can be quite strange; just make sure the name is valid by replacing - with _; if the package is doing something like AC_SUBST( ALSA_CFLAGS ) (which is what kenvy24gui did), remove the whitespace in the parenthesis, or the trailing whitespace will be considered part of the variable name!
• the way _GNU_SOURCE is defined has changed, not sure exactly how, the most prominent thing I can see is that the order of the defines in the generated config.h file is different, and that can cause problems if you have #include directives in your template file, like Linux-PAM had; I don’t have a solution, but you often can workaround it by adding append-flags -D_GNU_SOURCE to the ebuild, not a nice thing though;
• cached values are now checked to contain the cv string in them so that they can safely be cached, this causes crapload of warnings on software using very old libtool.m4 macros, which means almost everything using KDE’s build system, it’s not fatal though, not yet at least.

Additionally, you might have failures in autoconf when you’re using libtool 2.2, as it (finally!) doesn’t check for C++ and Fortran compilers every time – which by the way means that re-running autotools to use the new libtool macros is something that might actually save time rather than wasting it. There exists software that expected libtool to do the checking, and didn’t actually require for instance AC_PROG_CXX to look for the C++ compiler. In that case you just have to add the macro to the configure.ac file.

And again, please don’t revbump your package to add these fixes, people not updating to gcc 4.3 don’t want to rebuild their packages just because!