In article <20040513172915.36e99fae.hf@spg.tu-darmstadt.de>,
Hauke Fath <hf@spg.tu-darmstadt.de> wrote:
>Hi,
>
>I have Matlab running in console mode on a few i386 1.6.2 machines in
>the lab here. The same setup on a 2.0 machine, on the other hand, gives
>me 
>
>[hf@dobratsch] ~ > matlab -nojvm -glnx86
>/amd/montblanc/opt/matlabr13/bin/glnx86/matlab:
>/usr/lib/libpthread.so.0: no version information available (required by
>/amd/montblanc/opt/matlabr13/bin/glnx86/matlab)/amd/montblanc/opt/matla
>br13/bin/glnx86/matlab: /usr/lib/libpthread.so.0: no version information
>available (required by
>/amd/montblanc/opt/matlabr13/bin/glnx86/matlab)/amd/montblanc/opt/matla
>br13/bin/glnx86/matlab: /usr/lib/libpthread.so.0: no version information
>available (required
>by/amd/montblanc/opt/matlabr13/bin/glnx86/libut.so)/amd/montblanc/opt/m
>at labr13/bin/glnx86/matlab: /usr/lib/libpthread.so.0: no version
>information available (required by
>/amd/montblanc/opt/matlabr13/bin/glnx86/libut.so)/amd/montblanc/opt/mat
>labr13/bin/glnx86/matlab: error while loading shared libraries:
>/usr/lib/libpthread.so.0: undefined symbol: __sF
>[hf@dobratsch] ~ > uname
>-a NetBSD dobratsch.nt.e-technik.tu-darmstadt.de 2.0_BETA NetBSD
>2.0_BETA (GENERIC_DIAGNOSTIC) #1: Mon May 10 13:59:11 CEST 2004 
>hf@heiligenberg:/var/obj/netbsd-builds/2_0/i386/obj/sys/arch/i386/compi
>le/GENERIC_DIAGNOSTIC i386
>[hf@dobratsch] ~ >
>
>A ktrace doesn't tell much more. The linux emul packages are the same
>for both machine types (suse 7.3).
>
>Since this appears to be the one big related difference between
>NetBSD 1.6 and 2: How sure can I be that a linux binary does not try to
>pick up a NetBSD library (libpthread.so in this case)? 
>
>Don't laugh - when we attempted to call NEdit
>from within Matlab on a NetBSD 1.6 machine, we had to wrap NEdit in a
>shell script that reset LD_LIBRARY_PATH; otherwise it attempted to
>pick up a linux shared library. "Ouch."

Now, you re picking the NetBSD libpthread from a linux binary and this
will not work.

christos