Subject: Re: NetBSD packages and LD_LIBRARY_PATH
To: None <>
From: Joerg Sonnenberger <>
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 

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