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
> >>
> >>/opt/matlabr14/sys/os/glnx86:/opt/matlabr14/bin/glnx86:/opt/matlabr14/extern/lib/glnx86:/opt/matlabr14/sys/java/jre/glnx86/jre1.5.0/lib/i386/native_threads:/opt/matlabr14/sys/java/jre/glnx86/jre1.5.0/lib/i386/client:/opt/matlabr14/sys/java/jre/glnx86/jre1.5.0/lib/i386
> >> >>
> >
> >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.

Joerg