GNOME Bugzilla – Bug 586150
unresolved symbols when building glib 2.21.2 on OS X Tiger
Last modified: 2010-01-18 17:53:57 UTC
Please describe the problem: When compiling glib 2.21.2 on OS X Tiger it appears to be missing an include needed for a successful build. Steps to reproduce: 1. ./configure -q --prefix=/opt --disable-selinux --with-libiconv=gnu 2. make 3. Actual results: unresolved symbols: _res_9_dn_expand _res_9_init _res_9_search Expected results: successful build Does this happen every time? yes Other information: appending LIBS=-lresolv to the configure line fixes the unresolved symbols and lets the build finish properly. LIBS=-lresolv ./configure -q --prefix=/opt --disable-selinux --with-libiconv=gnu
This bug has also been reported to MacPorts, where someone has suggested a patch: http://trac.macports.org/ticket/20301 It wouldn't surprise me if this were more consequence of the feature about which I submitted bug 584574.
*** Bug 590482 has been marked as a duplicate of this bug. ***
Created attachment 146333 [details] [review] fix linking on OS X tiger uses -lresolv when building glib and gio etc (which actually seems to have basically no effect), like the macports patch, but also adds -lresolv to gio-2.0.pc on systems that need it. at least, on systems with _res_9_init in libresolv.
note that the macports patch does not fix linking gtk, because the glib/gio .dylibs have no dependency on libresolv, and thus the libresolv symbols are still missing.
Comment on attachment 146333 [details] [review] fix linking on OS X tiger The problem here (IIRC) is that "res_query" exists as a symbol in libSystem, so the AC_CHECK_FUNC() for it succeeds, but then the header files #define res_query to something else, which is found in libresolv. So the configure check for -lresolv needs to be changed to try to compile a program that #includes the headers we'll be #including and then using res_query, and that should cause it to (correctly) decide that it needs -lresolv, and link it in at the appropriate place, so that the dependencies end up right and modules higher up the stack link correctly without you needing to change the .pc files.
isn't part of the point of a .pc file specify additional libraries that are needed, not just the libraries that are part of the "package" being used? adding a fake call to res_query to force explicit linkage to libresolv seems equally ugly as modifying the gio-2.0.pc file.
(In reply to comment #6) > isn't part of the point of a .pc file specify additional libraries that are > needed, not just the libraries that are part of the "package" being used? No, that's the linker's job. libgio itself should be linked against libresolv, and then when other packages get linked against libgio, the linker will pull in libresolv automatically. This is what happens on all platforms that need -lresolv, except OS X. (Actually... it *would* be correct to add Libs.private=@LIBASYNCNS_LIBADD@ to gio-2.0.pc.in, for when you're statically linking and so the linker doesn't know about inter-library dependencies. But it does not need to be added to Libs) > adding a fake call to res_query to force explicit linkage to libresolv seems > equally ugly as modifying the gio-2.0.pc file. You misunderstand. The bug here is simply that OS X needs LIBASYNCNS_LIBADD="-lresolv", but configure is mistakenly concluding that it doesn't. The fix is to make the configure check more accurate, so it gets the right answer.
upstream libasyncns has a fixed configure check for this case, so dup'ing to that bug *** This bug has been marked as a duplicate of bug 598630 ***
(In reply to comment #7) > (In reply to comment #6) > You misunderstand. The bug here is simply that OS X needs > LIBASYNCNS_LIBADD="-lresolv", but configure is mistakenly concluding that it > doesn't. The fix is to make the configure check more accurate, so it gets the > right answer. unfortunately, that appears to not be true. adding -lresolv to the command line doesn't appear to generate a .dylib of libgio that has and link dependency on libresolv. it is possible that i screwed this up, but i tried the macports patch, rebuilt glib, check every dylib in the glib tree, and not one of them had a dependency on libresolv revealed by otool -L. i checked that -lresolv was being used in the link commands.
also, #598630 does not appear to be a duplicate of this bug or even related to it.
libasyncns's macro didn't work for this, but I wrote another one that should. should be fixed in master.
configure:26382: checking for res_query configure:26395: gcc -o conftest -arch ppc -g -Wall -Wno-long-double -pipe -no-cpp-precomp -Dsocklen_t=int -DMAC_OS_X_VERSION_MAX_ALLOWED=MAC_OS_X_VERSION_10_3 -I/opt/local/include -I/usr/X11R6/include -DG_DISABLE_SINGLE_INCLUDES -arch ppc -L/opt/local/lib -L/usr/X11R6/lib -framework Carbon conftest.c -lintl >&5 In file included from conftest.c:115: /usr/include/resolv.h:134: error: field `nsaddr_list' has incomplete type /usr/include/resolv.h:138: error: `MAXDNAME' undeclared here (not in a function) /usr/include/resolv.h:144: error: field `addr' has incomplete type configure:26395: $? = 1 configure test for res_query needs nameser.h included
Created attachment 151616 [details] [review] res_query blah i guess sys/types.h and netinet/in.h too
Created attachment 151668 [details] [review] More -lresolv-checking-fixing "#include <nameser.h>" fails on non-OS X. (Needs to be <arpa/nameser.h>) Does this fix it for you? Does changing from <nameser.h> to <arpa/nameser.h> make any of the other #includes unnecessary? (I removed the extra includes from the res_query-in--lbind check, because we know it's not going to get that far on OS X.)
yeah, that works arpa/nameser.h is just a symbolic link to nameser.h, the other includes are still needed