You know I always stress the point that it’s not autoconf (and automake) to be bad per-se, but rather the fact that it’s poorly documented and most people get the worst examples on how to do stuff.
One thing that I find totally misdesigned in autoconf though is the AC_CHECK_LIB macro. This macro is supposedly designed to look for certain functions in a library, to make sure that it’s linked upon if needed. The most simple case for this is using
AC_CHECK_LIB([dl], [dlopen])
to gather if the dlopen() function is in libdl or would be available directly from the C library. (Actually you usually use something more complex than this, but that’s another story).
What is the problem of this macro? Well, the problem comes when you check non-generic functions, because it has a side effect: if the function is found on the library, it is added to the LIBS variable, that is appended to every link line, causing the library to be linked in every target. This is fine when you only have one target, but it’s nasty in every other case.
This is one of the main cause of extra libraries being linked in on other libraries and executables, which are worked around with --as-needed (at least ELF side, as --as-needed does not help with libtool archives at all). It should really be avoided.
The easy way to avoid this is to reset the LIBS variable after AC_CHECK_LIB to the value it had before, it also helps if you set a new variable with the library you just detected, to use just where needed. A better way to handle this is to push on using pkg-config, which might not be the solution to all problems, but makes this problem quite easier to handle.
I know most people doing this mistake won’t be reading this, but at least I have it documented somewhere so that I can just point people at this post without repeating the reasoning. And yes, it’s problem like these that makes neon link against pam for no good reason.
or to specify action-if-found in there :AC_CHECK_LIB (library, function, [action-if-found], [action-if-not-found], [other-libraries])as per the autoconf documentation : http://www.gnu.org/software…But yeah I agree, people should be using pkg-config, it makes everything easier for everyone.
Quick addition, so the easy way to fix AC_CHECK_LIB([dl], [dlopen]) is to use AC_CHECK_LIB([dl], [dlopen], [])Easier than reseting LIBS and future-proof 🙂
IIRC even setting action-if-found didn’t work on older versions of autoconf, so although future-proof, it’s not entirely backward compatible. Which is one of the most obnoxious things autoconf, as a lot of distributions don’t update their autoconf in timely fashion.I had a hell of a time to convince people that xine _had_ to go with autoconf 2.59 at least, and still I can’t get it depend on 2.60’s behaviour.
well, for what i’ve experienced autoconf sometimes fails and i had a great pain when i switched profile and found about 10 packages (samba, libgdiplus for example, python) that weren’t able to build. the same xine-lib-1.2.9999.1 fails to autoconf, or at least it has failed yesterday when i last tried it.i’ve found out cmake to be much more fast and clean than autoconf+automake (at least for the end user) and to actually display the build progress (which is quite an interesting feature expecially for people on the move, which more and more are growing in numbers), but after reading your blogs about cmake i’m wondering how painful was for kde4 devs to use it efficiently.i’ve also read something about scons.it seem to have a python based config files and is cross-platform.i’ve also read that it was evaluated for the buildsystem for kde4 instead of cmake.
Actually, those macros should be circumvented whereever possible.Most libraries provide an pkg-config descriptor these days, so just use it whereever you can.
The following does *not* fix the problem: AC_CHECK_LIB([dl], [dlopen], [])You have to insert an additional space, otherwise the third argument does nothing: AC_CHECK_LIB([dl], [dlopen], [ ])