After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 586150 - unresolved symbols when building glib 2.21.2 on OS X Tiger
unresolved symbols when building glib 2.21.2 on OS X Tiger
Status: RESOLVED DUPLICATE of bug 598630
Product: glib
Classification: Platform
Component: gio
2.21.x
Other All
: Normal minor
: ---
Assigned To: gtkdev
gtkdev
: 590482 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-06-17 17:36 UTC by Steve Trotman
Modified: 2010-01-18 17:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fix linking on OS X tiger (689 bytes, patch)
2009-10-27 13:20 UTC, Paul Davis
rejected Details | Review
res_query blah (1.39 KB, patch)
2010-01-17 19:10 UTC, paul
none Details | Review
More -lresolv-checking-fixing (1.27 KB, patch)
2010-01-18 14:48 UTC, Dan Winship
committed Details | Review

Description Steve Trotman 2009-06-17 17:36:15 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
Comment 1 Ryan Schmidt 2009-07-15 21:23:39 UTC
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.
Comment 2 Dan Winship 2009-08-22 17:17:27 UTC
*** Bug 590482 has been marked as a duplicate of this bug. ***
Comment 3 Paul Davis 2009-10-27 13:20:30 UTC
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.
Comment 4 Paul Davis 2009-10-27 13:21:42 UTC
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 5 Dan Winship 2009-10-27 14:22:48 UTC
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.
Comment 6 Paul Davis 2009-10-27 14:27:15 UTC
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.
Comment 7 Dan Winship 2009-10-27 16:39:41 UTC
(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.
Comment 8 Dan Winship 2009-10-27 16:43:32 UTC
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 ***
Comment 9 Paul Davis 2009-10-27 16:52:47 UTC
(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.
Comment 10 Paul Davis 2009-10-27 16:55:09 UTC
also, #598630 does not appear to be a duplicate of this bug or even related to it.
Comment 11 Dan Winship 2010-01-13 17:06:39 UTC
libasyncns's macro didn't work for this, but I wrote another one that
should. should be fixed in master.
Comment 12 paul 2010-01-17 18:42:52 UTC
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
Comment 13 paul 2010-01-17 19:10:02 UTC
Created attachment 151616 [details] [review]
res_query blah

i guess sys/types.h and netinet/in.h too
Comment 14 Dan Winship 2010-01-18 14:48:13 UTC
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.)
Comment 15 paul 2010-01-18 16:05:32 UTC
yeah, that works
arpa/nameser.h is just a symbolic link to nameser.h, the other includes are still needed