On Sun, Nov 06, 2005 at 07:25:08PM +1100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > >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?
No I'm saying that it should not be there so that one can use other library paths with LD_LIBRARY_PATH as they would do with other software. As you are doing with your other software. > >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? Probably. And he might get a bug report similar to the one we got some day. Or not. Since it's very corner case and won't happen that much. But still that's not a reason to break these corner cases while fixing the problem as it should be fixed doesn't harm. > 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. The point is to ensure that the binary gets what it needs and is not in system directories. i.e. libraries in /usr/lib/mozilla-firefox and plugins. > 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. You just don't get it. Just use wrapper scripts for the software you want to use with your non-debian libraries. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
