Subject: Re: NetBSD packages and LD_LIBRARY_PATH
To: None <tech-pkg@netbsd.org>
From: Joerg Sonnenberger <joerg@britannica.bec.de>
List: tech-pkg
Date: 10/25/2005 12:20:40
On Tue, Oct 25, 2005 at 11:43:03AM +0200, Hauke Fath wrote:
> Hi,
> 
> recently I got complaints from users who called native NetBSD 
> applications from Matlab's shell exit and saw them fail. When I 
> investigated 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 :-)

> 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.

> 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?

Joerg