On Fri, 2006-11-24 at 17:26 +0100, Fabian Groffen wrote:
> On 24-11-2006 17:16:20 +0100, Michael Haubenwallner wrote:
> > WARNING: This e-mail has been altered by MIMEDefang. Following this
> > paragraph are indications of the actual changes made. For more
> > information about your site's MIMEDefang policy, contact
> > MIMEDefang Administrator's Full Name <[EMAIL PROTECTED]>. For more
> > information about MIMEDefang, see:
> >
> > http://www.roaringpenguin.com/mimedefang/enduser.php3
> >
> > An attachment named '00-solaris.sh' was converted to 'defang-1.binary'.
> > To recover the file, right-click on the attachment and Save As
> > '00-solaris.sh'
>
> wtf is right-clicking, and how the hell do I do "Save As"?
>
> now you got me confused ;)
That damn silly virus scanner knows that '*.sh' is a virus :(
Have attached again, but without .sh in filename.
<snip>
> > $ echo $LD_LIBRARY_PATH
> >
> > /usr/local/lib:/usr/sfw/lib:/usr/local/gcc-3.3.6/lib:/opt/sfw/lib:/oracle10/product/10.1.0/lib
>
> That's why LD_LIBRARY_PATH is evil, and can crash Macs ;)
And Solaris. And Linux. And ia64-hpux i assume.
<snip>
> I can't see your solution inline, but I suspect you prepend prefix
> paths, such they are searched first.
exactly, but only if LD_LIBRARY_PATH is set already.
>
> I am against such stuff, because LD_LIBRARY_PATH is "evil". It only
> introduces problems, when used as global as this. So in my opinion,
> LD_LIBRARY_PATH (or similar) will never ever get supported. To give you
> an example as to why I think LD_LIBRARY_PATH shouldn't be used, consider
> the following real life experience:
>
> On a Mac, various applications link to libjpeg. Not so weird, Aqua is a
> strongly graphical biased window manager. Anyhow, the version of
> libjpeg which Apple uses, is "outdated". In prefix, we have a newer,
> and incompatible version installed. Having DYLD_LIBRARY_PATH set to
> prefix lib paths, causes any Aqua app to crash with a kernel trap from
> the linker, because a wrong libjpeg is found. Even if those
> applications would have built in run-paths (-R, -rpath) they are boldly
> overridden by DYLD_LIBRARY_PATH and hence maby spectaculair things can
> happen.
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.
So maybe we should unset LD_LIBRARY_PATH ?
>
> 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...
/haubi/
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
