GNOME Bugzilla – Bug 673253
Not strict enough autconf test for libelf
Last modified: 2012-06-05 18:19:16 UTC
I'm building glib-2.32.0 on OS X 10.6 (forcing arch i386), using XCode-4.2 via fink. In order to make libraries more able to be dlopen()ed and generally less likely to cause problems for others that would link against them due to missing -l flags, I activate -no-undefined in the makefiles. I have a "libelf" installed, (version 0.8.9 from http://directory.fsf.org/libs/misc/libelf.html). As a result, ./configure finds it: checking for elf_begin in -lelf... yes However, later during the build I get: CC gresource-tool.o gresource-tool.c: In function 'elf_foreach_resource_section': gresource-tool.c:174: warning: implicit declaration of function 'elf_getshdrstrndx' gresource-tool.c:177: warning: implicit declaration of function 'elf_getshdrnum' and finally building fails with: CCLD gresource Undefined symbols for architecture i386: "_elf_getshdrstrndx", referenced from: _cmd_extract in gresource-tool.o _cmd_sections in gresource-tool.o _cmd_list in gresource-tool.o "_elf_getshdrnum", referenced from: _cmd_extract in gresource-tool.o _cmd_sections in gresource-tool.o _cmd_list in gresource-tool.o ld: symbol(s) not found for architecture i386 collect2: ld returned 1 exit status make[4]: *** [gresource] Error 1 I'm assuming those symbols are only available in a newer version or only in the linux (or other platform/vendor-specific supplier) of that library. If I uninstall my libelf package, building of gresource-tool.o has no warnings and linking of gresource succeeds. So configure should test for one of those more novel parts of that lib's API in addition to (or instead of) just elf_begin and/or a specific version-number of that lib rather than just its presence.
Also see bug 673132
Looks like my distro does not have the latest libelf package (directory.fsf.org seems out-of-date vs "real" upstream). The README for the current version (0.8.13) states: Changes since 0.8.11: * Due to some unfortunate confusion, the elf_getphnum(), elf_getshnum() and elf_getshstrndx() are not compatible between libelf implementations. Therefore, the developers decided to replace them with new functions: elf_getphdrnum(), elf_getshdrnum() and elf_getshdrstrndx(), which will always return -1 on failure and 0 on success. Code using the old interface should be upgraded to increase portability. so I would need libelf >= 0.8.12 (for this author's versioning) to have the symbols glib wants (assuming detection could be reduced to a version-test, cf. other bugs' .pc chaos). The alternative of implementing fallback code using the older symbols when the newer one isn't found is...fragile and not worth the effort IMO.
I've committed a more thorough configure check now, maybe you can try that ?
glib-2.32.3 still fails the same way because the test is still written based on simple detection of the libelf dependency: I do have libelf.pc on my system. The theme of the change to configure.ac is a fallback alternative test for specific symbols *when PKG_CHECK_MODULES fails*, not a confirmation that the libelf that is detected by PKG_CHECK_MODULES is sufficient. As I stated in Comment #2, PKG_CHECK_MODULES would need to test for "libelf >= 0.8.12" not mere presence, if P_C_M is going to be treated as a "sufficient" test for libelf.
There's also a bug in the multiple-calls-to-AC_CHECK_LIB fallback approach: that macro appears to AC_DEFINE HAVE_LIBELF when it succeeds, so a series of calls for different symbols in the same lib gives the logical "or" of them not "and". So even though some of them fail, which sets have_libelf to "no" and does not set HAVE_LIBELF via this later bit of logic: if test $have_libelf = yes; then AC_DEFINE(HAVE_LIBELF, 1, [Define if libelf is available]) fi the token is still defined and the elf support code in gresource-tool.c is activated.
Created attachment 215663 [details] [review] Require .pc version, or else require *all* used symbols The attached patch solves both problems. I have libelf (one that supplies libelf.pc) but it's an apparently older version that does not have the needed symbols. My ./configure with this patch reports: checking for LIBELF... no checking for elf_begin... yes checking for elf_getshdrstrndx... no checking for elf_getshdrnum... no checking libelf.h usability... yes checking libelf.h presence... yes checking for libelf.h... yes and HAVE_LIBELF is *not* defined so the libelf support code is not activated
hmm, I couldn't find this bug when I was looking, before doing the glib release, because bugzilla was down, and when I changed the test to look for elf_getxxx instead, it correctly did not set HAVE_LIBELF, so I thought things were fine. We'll pick this up for the next release then.
(In reply to comment #6) > Created an attachment (id=215663) [details] [review] > Require .pc version, or else require *all* used symbols Please see https://live.gnome.org/GnomeLove/SubmittingPatches for how to submit patches via git. The second part of your patch was already in master, so I just did the first part: http://git.gnome.org/browse/glib/commit/?id=4690d85607da879e50746db64ea99a273823c25e