mozilla-developers: libxpcom/gtkmozembed and -rpath

[Volker Stolz]

The gtkmozembed plugin must be compiled with -Wl,-rpath,${X11BASE}/lib/mozilla
or the same path should be passed to ldconfig via INSTALLS_SHLIB. Otherwise,
applications linking against libgtkembezmod.so won't run since they can't find
the other libraries:

root at menelaos# readelf -a libgtkembedmoz.so | grep PATH
 0x0000000f (RPATH)                      Library rpath: [/usr/X11R6/lib:/usr/local/lib]
root at menelaos# ldd ./libgtkembedmoz.so
./libgtkembedmoz.so:
        libxpcom.so => not found (0x0)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2812e000)
        libplds4.so => not found (0x0)
        libplc4.so => not found (0x0)
        libnspr4.so => not found (0x0)
        ...
root at menelaos# ./TestGtkEmbed (somewhere in the mozilla-port)
/usr/libexec/ld-elf.so.1: Shared object "libxpcom.so" not found, required by "libgtkembedmoz.so"

Interlude: How does 'mozilla' itself handle this?
/usr/X11R6/lib/mozilla contains a shell wrapper that sets up LD_LIBRARY_PATH.
Clearly, we don't want to have to do this for every application that links against
libgtkembedmoz, libxpcom and friends.
In fact, Gentoo stores the libs in /usr/lib/mozilla and uses -rpath on compilation.
Debian has the libs in /usr/lib anyway.

You can check devel/devhelp or x11/yelp for the hoops to jump to. In fact, running ldconfig
is only necessary because of the botched -rpath-issue. If ldconfig'uring this
directory is the preferred solution, this should be done in the mozilla port.
OTOH, I think devhelp should rather use LD_LIBRARY_PATH instead of poisoning
ldconfig, see the last paragraph for the rationale.

Now follows a walk-through which shows how to fix this, although somebody with
more knowledge of the mozilla-build-infrastructure is required since I can't figure
out how to patch this into the build:

Manually compiling libgtkembedmoz.so with -rpath yields:
root at menelaos# readelf -a libgtkembedmoz.so | grep PATH
 0x0000000f (RPATH)                      Library rpath: [/usr/X11R6/lib:/usr/local/lib:/usr/X11R6/lib/mozilla] 

Rebuild test-app with -rpath to link against port-local versions of the libs:
c++  -I/usr/X11R6/include  -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pipe -g -O2 -Wall -pipe  -DNDEBUG -DTRIMMED  -I/usr/local/include/atk-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/X11R6/include/gtk-2.0 -I/usr/X11R6/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/X11R6/include/pango-1.0 -I/usr/local/include/freetype2 -I/usr/local/include   -o TestGtkEmbed TestGtkEmbed.o    -L../../../../dist/bin -L../../../../dist/lib -Wl,-rpath,../../../../dist/lib -lgtkembedmoz -L/usr/X11R6/lib -lX11   -lm  -L../../../../dist/bin -lmozjs -L../../../../dist/bin -lxpcom  -L/usr/local/lib -liconv -L../../../../dist/bin -L/usr/ports/www/mozilla/work/mozilla/dist/lib -lplds4 -lplc4 -lnspr4 -pthread  -Wl,-rpath,/usr/X11R6/lib -Wl,--rpath -Wl,/usr/local/lib -L/usr/X11R6/lib -lgtk-x11-2.0

root at menelaos#
./TestGtkEmbed /usr/libexec/ld-elf.so.1: Shared object "libplds4.so" not found, required by "libmozjs.so" 

===> We're one step further, now finding out the libmozjs.so should have been compiled
with -rpath as well.

I should think that this is a Well Known Issue for the mozilla-developers and I'd
expect some switch hidden in the infrastructure to enable this. Note that simply
ldconfig'uring the path isn't really an option for exactly the same reason -rpath
was invented for [1].

References:
[1] http://tinyurl.com/c7olh
-- 
http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME
Receive and transmit