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 509715 - gnome-vfs build fails: undefined _res_9_init due to missing -lresolv in LIBGNOMEVFS_LIBS
gnome-vfs build fails: undefined _res_9_init due to missing -lresolv in LIBGN...
Status: RESOLVED WONTFIX
Product: gnome-vfs
Classification: Deprecated
Component: Build
2.20.x
Other All
: Normal blocker
: ---
Assigned To: gnome-vfs maintainers
gnome-vfs maintainers
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2008-01-15 18:06 UTC by Vincent Lefevre
Modified: 2018-08-17 13:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Vincent Lefevre 2008-01-15 18:06:32 UTC
Please describe the problem:
On Mac OS X 10.4.11, gnome-vfs build fails with the error:

ld: Undefined symbols:
_res_9_dn_expand
_res_9_init
_res_9_search

Adding -lresolv to LIBGNOMEVFS_LIBS in libgnomevfs/Makefile after configure solves the problem. Note that -lresolv was already present in the variables GSSAPI_LIBS and NEON_LIBS; so, I assume that this is just something missing for the configure script.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Daniel Macks 2008-01-22 23:46:14 UTC
libgnomevfs itself doesn't use gssapi or other kerberos stuff I don't think and gssapi can be disabled via ./configure, so "passing GSSAPI_LIBS when linking libgnomevfs" isn't an ideal solution. The res_9_* symbols are used from gnome-vfs-dns-sd.o: gnome-vfs-dns-sd.c calls them without the "res_9_" prefix (i.e., just "dn_expand"). Something external to gnome-vfs itself gives that prefix ('grep -rl res_9 gnome-vfs-2.20.1' gives no matches) and OS X does have those symbols without the prefix (libSystem defines dn_expand, so no -l flag needed).
Comment 2 Daniel Macks 2008-01-22 23:54:25 UTC
Ahah, /usr/include/resolv.h, which is #included by gnome-vfs-dns-sd.c, has:

#define dn_expand                         res_9_dn_expand

and likewise for all the other resolver symbols. Wouldn't be hard to write a ./configure test for this, can't believe such a crazy thing is needed. The resolver(3) manpage on 10.4 gives the functions as just dn_expand and so on (no prefix) and the .c here uses the identical #include incantation as given in the manpage too.
Comment 3 André Klapper 2008-11-15 21:31:22 UTC
Is this still a valid issue in gnome-vfs 2.24?

Also note that gnome-vfs has been deprecated and superseded by gio/gvfs since GNOME 2.22.
Comment 4 Daniel Macks 2008-11-15 21:58:23 UTC
Fink's package for gnome-vfs-2.24.0 still hacks to add the -lresolv flag. According to 'nm', the reslting libgnomevfs still uses libresolv to resolve (sorry:) those three res_9_* symbols.

Unfortunately, gnome-vfs is a low-level dependency of many other things directly or (even once they are fixed) via libgnome. Given libgnome being deprecated, I don't know if it will be fixed to use gio/gvfs, or how soon *that* legacy package can be rooted out:(
Comment 5 André Klapper 2018-08-17 13:46:54 UTC
gnome-vfs got deprecated in 2008.

gnome-vfs is not under active development anymore and had its last code changes
in 2011. Its codebase has been archived:
https://gitlab.gnome.org/Archive/gnome-vfs/commits/master

gio (in glib) and gvfs are its successors. See https://developer.gnome.org/gio/stable/ch33.html and https://people.gnome.org/~gicmo/gio-migration-guide/ for porting info.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Feel free to open a task in GNOME Gitlab if the issue described in this task still applies to a recent + supported version of glib/gio/gvfs. Thanks!