Subject: Re: NetBSD packages and LD_LIBRARY_PATH
To: None <tech-pkg@NetBSD.org>
From: Joerg Sonnenberger <email@example.com>
Date: 10/26/2005 10:32:03
On Tue, Oct 25, 2005 at 04:20:32PM +0200, Hauke Fath wrote:
> Am 25.10.2005 um 12:20 Uhr +0200 schrieb Joerg Sonnenberger:
> >On Tue, Oct 25, 2005 at 11:43:03AM +0200, Hauke Fath wrote:
> > > [...] I found that those applications (typically of the more
> > > complex variant, like XEmacs or Firefox) tend to pick up Linux shared
> >> libraries. The environment that Matlab sets up for a shell exit
> >> contains
> >> >> !echo $LD_LIBRARY_PATH
> >> >>
> >That's the reason why I normally install the programs completely under
> >/usr/pkg/emul :-)
> That's a WA^Weducated guess, since I haven't actually done a
> re-install of Matlab to /usr/pkg/emul/linux/opt, but -- wouldn't the
> paths in LD_LIBRARY_PATH show up just the same since a linux binary
> sets them up against the emulation root?
It means that LD_LIBRARY_PATH would point into nowhere for non-Linux
binaries, so it would be effectively ignored.
> > > which apparently is enough to confuse said applications. A wrapper
> >> script that unsets LD_LIBRARY_PATH successfully works around this;
> >> but it adds to the perception that NetBSD "always has to be a bit
> >> more complicated".
> >It is not a NetBSD problem, the same happens on Linux, but the results
> >are not as bad.
> Well... I just started Matlab R13 from a shell escape out of Matlab
> R14, and it worked. So it would seem a linux binary can live with the
> libraries it finds along that path - probably in addition to what is
> set up in the Linux /etc/ld.so.conf.
Yes, it can live with them. As long as you don't have binaries which
need e.g. a never version of a library which is now not automatically
picked up. LD_LIBRARY_PATH is deprecated for a reason.
> > > Since NetBSD considers LD_LIBRARY_PATH deprecated for ELF binaries:
> >> Is there a way of globally keeping native binaries from looking at
> >> LD_LIBRARY_PATH?
> >Well, you could make them suid/sgid, but otherwise no. LD_LIBRARY_PATH
> >can not be avoided in some situations, even though stupid wrapper
> >scripts are concertainly not that reason.
> >Have you looked at using chrpath to eliminiate the need for the
> >LD_LIBRARY_PATH in Matlab?
> Would that keep it from handing the LD_LIBRARY_PATH (which is set up
> in the matlab startup script) over to a spawned shell?
If you change the matlab binary/ies to have embedded RPATH entries, you
wouldn't need to set LD_LIBRARY_PATH at all.