Date: Fri, 28 Oct 2005 11:24:09 +0200 From: Volker Stolz <vs@FreeBSD.org> To: ports@FreeBSD.org Cc: kwm@FreeBSD.org Subject: mozilla-developers: libxpcom/gtkmozembed and -rpath Message-ID: <20051028092409.GA20996@i2.informatik.rwth-aachen.de>
next in thread | raw e-mail | index | archive | help
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@menelaos# readelf -a libgtkembedmoz.so | grep PATH
0x0000000f (RPATH) Library rpath: [/usr/X11R6/lib:/usr/local/lib]
root@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@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@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051028092409.GA20996>