Date: Fri, 28 Nov 2003 12:58:05 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: gnome@FreeBSD.org Subject: Gnome libraries record build directory in RPATH Message-ID: <20031128205805.GA19394@dhcp01.pn.xcllnt.net>
next in thread | raw e-mail | index | archive | help
Gang,
I'm looking into runtime issues with gnome applications on ia64
and I see odd behaviour WRT shared library dependencies. I think
it's harmless, but it probably does affect performance. The
following is mostly a FYI...
Take for example gconfd-2:
itanium% ldd gconfd-2
gconfd-2:
libintl.so.5 => /usr/local/lib/libintl.so.5 (0x2000000040080000)
libORBit-2.so.0 => /usr/local/lib/libORBit-2.so.0 (0x20000000400a2000)
libgobject-2.0.so.200 => /usr/local/lib/libgobject-2.0.so.200 (0x2000000040156000)
libm.so.2 => /lib/libm.so.2 (0x2000000040208000)
libgmodule-2.0.so.200 => /usr/local/lib/libgmodule-2.0.so.200 (0x2000000040254000)
libgthread-2.0.so.200 => /usr/local/lib/libgthread-2.0.so.200 (0x200000004026a000)
libkse.so.1 => /usr/lib/libkse.so.1 (0x2000000040284000)
** libglib-2.0.so.200 => /usr/local/lib/libglib-2.0.so.200 (0x20000000402e4000)
libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2000000040420000)
libgconf-2.so.5 => /usr/X11R6/lib/libgconf-2.so.5 (0x2000000040540000)
libc.so.5 => /lib/libc.so.5 (0x20000000405c0000)
libpopt.so.0 => /usr/local/lib/libpopt.so.0 (0x2000000040798000)
** libglib-2.0.so.200 => /usr/obj/nfs/freebsd/ports/devel/glib20/work/glib-2.2.3/glib/.libs/libglib-2.0.so.200 (0x20000000407b6000)
I marked two references to libglib-2.0.0.so.200. The first is the one
that's installed (the official one). The second is the one in the
build directory. Besides the fact that we have 2 references to the
same library, it's hardly useful to have a dependency to a build
directory -- it's almost never present and if it is, it can cause
problems.
With the -a option to ldd, I get (stripped):
gconfd-2:
libglib-2.0.so.200 => /usr/local/lib/libglib-2.0.so.200 (0x20000000402e4000)
/usr/local/lib/libORBit-2.so.0:
libglib-2.0.so.200 => /usr/local/lib/libglib-2.0.so.200 (0x20000000402e4000)
/usr/local/lib/libgobject-2.0.so.200:
libglib-2.0.so.200 => /usr/obj/nfs/freebsd/ports/devel/glib20/work/glib-2.2.3/glib/.libs/libglib-2.0.so.200 (0x20000000407b6000)
/usr/local/lib/libgmodule-2.0.so.200:
libglib-2.0.so.200 => /usr/obj/nfs/freebsd/ports/devel/glib20/work/glib-2.2.3/glib/.libs/libglib-2.0.so.200 (0x20000000407b6000)
/usr/local/lib/libgthread-2.0.so.200:
libglib-2.0.so.200 => /usr/obj/nfs/freebsd/ports/devel/glib20/work/glib-2.2.3/glib/.libs/libglib-2.0.so.200 (0x20000000407b6000)
Looking at the dependencies recorded in libgobject, we see:
itanium% readelf -d libgobject-2.0.so.200
Dynamic segment at offset 0x9d4d0 contains 21 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libintl.so.5]
0x0000000000000001 (NEEDED) Shared library: [libglib-2.0.so.200]
0x000000000000000e (SONAME) Library soname: [libgobject-2.0.so.200]
0x000000000000000f (RPATH) Library rpath: [/usr/obj/nfs/freebsd/ports/devel/glib20/work/glib-2.2.3/glib/.libs:/usr/local/lib]
:
So there it is. Some GNOME libraries have the build directory recorded
in RPATH. This generally is a mistake. Note that this also happens on
i386, so it's not an ia64 specific problem. It does appear to be a
FreeBSD specific problem. I don't see it on Linux (I checked both RH 8
on i386 and RH AS3.0 on ia64).
Anyway: FYI,
--
Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031128205805.GA19394>