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 ;)
> Hi,
>
> if one does "source ${EPREFIX}/etc/profile" to switch to prefix, and
> there's an LD_LIBRARY_PATH preset from system (why ever), some binaries
> in prefix might not work, because they might find different sharedlibs
> than they are expected to do:
>
> $ . /tools/haubi/gentoo/sauxy3/etc/profile
> $ type groff
> /tools/haubi/gentoo/sauxy3/usr/bin/groff
> $ ldd /tools/haubi/gentoo/sauxy3/usr/bin/groff
> libstdc++.so.6 => /usr/sfw/lib/libstdc++.so.6
> libstdc++.so.6 (GLIBCXX_3.4) => (version not found)
> libstdc++.so.6 (CXXABI_1.3) => (version not found)
> libm.so.2 => /lib/libm.so.2
> libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1
> libc.so.1 => /lib/libc.so.1
> $ 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 ;)
> So, I put attached file into ${EPREFIX}/etc/profile.d/00-solaris.sh,
> which could be generated by some baselayout and gets sourced by
> etc/profile, ldd then says:
>
> $ echo $LD_LIBRARY_PATH
>
> /tools/haubi/gentoo/sauxy3/lib:/tools/haubi/gentoo/sauxy3/usr/lib:/usr/local/lib:/usr/sfw/lib:/usr/local/gcc-3.3.6/lib:/opt/sfw/lib:/oracle10/product/10.1.0/lib
> $ ldd /tools/haubi/gentoo/sauxy3/usr/bin/groff
> libstdc++.so.6 =>
> /net/toolsjunk/haubi/gentoo/sauxy3/lib/libstdc++.so.6
> libm.so.2 => /lib/libm.so.2
> libgcc_s.so.1 =>
> /net/toolsjunk/haubi/gentoo/sauxy3/lib/libgcc_s.so.1
> libc.so.1 => /lib/libc.so.1
>
> This is the same as when unsetting LD_LIBRARY_PATH, which I don't want
> to do in this case, because I want continue to use some executables from
> outside the prefix.
>
> Thing is, when LD_LIBRARY_PATH is preset, builtin DT_RUNPATH
> (LDFLAGS=-Wl,-R...) is searched too late to find the correct libraries.
I can't see your solution inline, but I suspect you prepend prefix
paths, such they are searched first.
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.
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.
--
Fabian Groffen
Gentoo on a different level
--
[EMAIL PROTECTED] mailing list
