On Mon, Feb 09, 2009 at 08:42:03AM +0000, Jack Stone wrote: > Ken Moffat wrote: > > > > If I configure with > > LD_LIBRARY_PATH=/usr/lib/xulrunner-devel-1.9.0.6/lib > > configure is happy. > > > > Similarly, if I set up symlinks for the nspr libs in /usr/lib, > > configure is happy. In fact, that's what I did a few months ago > > when I first hit this (before I moved on to separate nss, nspr to > > get this to build on ppc), but I'm not happy using a workaround for > > a problem I don't even understand! > > If I understand shared libraries correctly the -L only helps find the > lib at link time. > Thanks, but my reading of the error message is that the failure did indeed happen at link time.
> Libtool --mode=finish gives a list of the possible ways of doing this. > The ones I remember are LD_LIBRARY_PATH (as you found), ld.so.conf (as > you suggested) and possibly some -rpath foo which I don't understand. > Thanks for that. The others are LD_RUN_PATH and '-Wl,-rpath -Wl,LIBDIR'. > The symlinks help because it puts the lib in the default search path for > the dynamic linker. > Yes. I still don't understand why -L is failing. > I know this probably doesn't help with a solution, but I hope it clears > up what is happening. > Well, I'm a little bit nearer to understanding it. Using symlinks from /usr/lib is probably the least dangerous (if you do them when you compile xulrunner, you know the version, and are more likely to remember to update them when updating xulrunner). Actually, I've a suspicion I got the idea from debian, who just move a lot of libraries to /usr/lib. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-chat FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
