On 24-11-2006 17:56:18 +0100, Michael Haubenwallner wrote:
> Yes, I know such examples. Question is, what is less bad out of these
> three possibilities:
>
> 1) leaving LD_LIBRARY_PATH alone:
> system-installed binaries will work
> eprefixed ones might not.
>
> 2) unsetting LD_LIBRARY_PATH:
> eprefixed binaries will work
> some system-installed binaries don't find their sharedlibs and won't
> start at all.
>
> 3) prepending LD_LIBRARY_PATH:
> eprefixed binaris will work
> some system-installed binaries might find the wrong sharedlib and will
> not work correctly.
>
> Hmm, when looking at these ones, I begin to like 2) more than 3)...
>
> For 2), there's another possible way to do without LD_LIBRARY_PATH:
> Use 'crle(1)' to inform runtime loader about that search pathes.
I have to do homework on this one.
> So maybe we should unset LD_LIBRARY_PATH ?
Currently my opinion is, that if and only if we do something with
LD_LIBRARY_PATH, it should be that we unset it.
> > So, never ever touch LD_LIBRARY_PATH, if you need it, you're on your
> > own, and should probably fix your apps, or build wrapper scripts that
> > set LD_LIBRARY_PATH temporarily.
>
> Hmm, having wrapper scripts in ${EPREFIX}/usr/local/bin sounds
> interesting...
Acroread for instance does this, and I think firefox too. In their
controlled setting where they have all libs anyway that works out pretty
fine.
> if [ -n "${LD_LIBRARY_PATH}" ]; then
>
> LD_LIBRARY_PATH=/tools/haubi/gentoo/sauxy3/lib:/tools/haubi/gentoo/sauxy3/usr/lib:${LD_LIBRARY_PATH}
> export LD_LIBRARY_PATH
> fi
--
Fabian Groffen
Gentoo on a different level
--
[EMAIL PROTECTED] mailing list
