Gnome libraries record build directory in RPATH

[Marcel Moolenaar]

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 at xcllnt.net