From owner-freebsd-ports@FreeBSD.ORG Fri Oct 28 09:24:20 2005 Return-Path: X-Original-To: ports@FreeBSD.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B98A16A41F; Fri, 28 Oct 2005 09:24:20 +0000 (GMT) (envelope-from stolz@i2.informatik.rwth-aachen.de) Received: from atlas.informatik.rwth-aachen.de (atlas.informatik.RWTH-Aachen.DE [137.226.194.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB9FD43D45; Fri, 28 Oct 2005 09:24:18 +0000 (GMT) (envelope-from stolz@i2.informatik.rwth-aachen.de) Received: from i2.informatik.rwth-aachen.de (menelaos.informatik.RWTH-Aachen.DE [137.226.194.73]) by atlas.informatik.rwth-aachen.de (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9S9OHXB028155; Fri, 28 Oct 2005 11:24:17 +0200 Received: (from stolz@localhost) by i2.informatik.rwth-aachen.de (8.13.1/8.13.1/Submit) id j9S9OB0C021601; Fri, 28 Oct 2005 11:24:11 +0200 (CEST) (envelope-from stolz) Received: (hashcash-sendmail, from uid 1228); Fri, 28 Oct 2005 11:24:11 +0200 Date: Fri, 28 Oct 2005 11:24:09 +0200 From: Volker Stolz To: ports@FreeBSD.org Message-ID: <20051028092409.GA20996@i2.informatik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: finger vs@foldr.org X-PGP-Id: 0x3FD1B6B5 User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:051028:ports@freebsd.org::U4sz/tlYzyf9aEA4:00000000000000000000 000000000000000000000000DCfd X-Hashcash: 1:20:051028:kwm@freebsd.org::OkNDnUn79Pb5a4r6:001wIN Cc: kwm@FreeBSD.org Subject: mozilla-developers: libxpcom/gtkmozembed and -rpath X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 09:24:20 -0000 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