And what about people that actually intend to use libraries from other
locations instead of those in /lib, without breaking firefox ?
Sorry, but I'm not following you. How would that come about?
The library in question is libgcc_s.so.1.
When would someone running a 'stable' system need to change the
location of that library?
p.d.o tells me that lib exists in libgcc1 and lib64gcc1 in /lib &
/lib64, respectively. Are you saying that the firefox wrapper should
not contain /lib in LD_LIBRARY_PATH so that it works on 32-bit &
64-bit arches?
Ah, by the way, /usr/lib has been removed from LD_LIBRARY_PATH in
1.0.7-1... I see no reason to put it back, nor add /lib. See bug #321789.
So why did the maintainer of mozilla accept this change? Were they wrong?
Given /usr/lib was there before, it seemed ok to just enforce the
ld_path for _all_ the libraries the browser was trying to load.
I compared the differences between the two ldd runs in Julien's report
and it seems that part of his problem was coming from some libs being
picked up from /usr/lib/ instead of /usr/lib/mozilla-firefox/;
for example /usr/lib/libmozjs.so (which comes from 'mozilla-browser').
The other part was the problem with libXinerama, where it does seem
possible /usr/lib was put in LD_LIBRARY_PATH instead of /usr/X11R6/lib.
If this was indeed the source of the /usr/lib entry in the first place
then maybe it is better to exclude :/usr/lib:/lib from the ld_path.
I thought the point of overriding an existing LD_LIBRARY_PATH in a
wrapper script was to ensure the binary got exactly what it needed
to run. Just as you showed me in your example code, and just as you
have to do to make sure to get /usr/lib/mozilla-firefox/libmozjs.so,
not the one installed by mozilla-browser. Is the difference here that
you are only prefixing enough to LD_LIBRARY_PATH to force use of the
libs you're providing?
Julien's problem seems to have been that somewhere in /usr/lib
is a library that provides some symbols that are also provided
from /usr/X11R6/lib. It's unclear what that could be. I did a
bit of poking around but could not see anything obvious.
The only things from his ldd output which are in /usr/lib and
refer to XineramaIsActive on my (sarge) system are
/usr/lib/mozilla-firefox/firefox-bin
/usr/lib/libgdk-x11-2.0.so.0
I also tried the same test as he did
$ unset LD_LIBRARY_PATH
$ LD_LIBRARY_PATH=/usr/lib/mozilla-firefox:/usr/X11R6/lib ldd -d -r \
/usr/lib/mozilla-firefox/firefox-bin
$ LD_LIBRARY_PATH=/usr/lib/mozilla-firefox:/usr/lib ldd -d -r \
/usr/lib/mozilla-firefox/firefox-bin
and saw no differences in the library resolutions.
For the record, my /etc/ld.so.conf is this
/usr/lib/libc5-compat
/lib/libc5-compat
/usr/i486-linuxlibc1/lib
/usr/X11R6/lib
/usr/lib/sse2/atlas
/usr/lib/atlas/sse2
/usr/lib/sse2
/usr/lib/atlas
The only reason I can offer for adding :/usr/lib:/lib to LD_LIBRARY_PATH
is to override what I think is a common case, where people are building
software that Debian doesn't provide (e.g. their own software) with a
newer compiler and need LD_LIBRARY_PATH to pick up the libgcc for that
compiler.
Changing the firefox wrapper to make it more self-contained and robust
doesn't seem to be a problem to me. But if by that reasoning the full
solution is adding
:/usr/X11R6/lib:/usr/lib:/lib
or even
:/usr/X11R6/lib:/usr/lib64:/lib64:/usr/lib:/lib
to the EXTENT_LD_LIB_PATH then this is starting to get silly I guess.
So I'm stuck with patching this silly thing? Teerificthanksabunch.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
