[SciPy-dev] [mlabwrap] linker path

David Cournapeau david@ar.media.kyoto-u.ac...
Tue Oct 20 19:45:41 CDT 2009


Clemens Buchacher wrote:
> Is it common practice not to Cc the OP on this list? Luckily, I just
> registered yesterday.
>
> On Tue, Oct 20, 2009 at 12:25:51PM +0900, David Cournapeau wrote:
>
>   
>> On the "bright" side, I doubt that the new mlabwrap changes anything:
>> when mlabwrap used ctypes and loaded the matlab engine through ctypes,
>> the old zlib was likely loaded as well through rpath links.
>>     
>
> Yeah, pre-1.1 has the matlab path hardcoded. I'm not sure if I like that or
> not.
>
>   

That's not what I mean: when you load libeng.so, the loader
automatically loads the dependend libraries, including libz, according
to the rpath. On my machine, ldd libeng.so returns:

linux-gate.so.1 =>  (0xb7ef0000)
    libut.so => /home/speech/matlab/bin/glnx86/./libut.so (0xb7e4b000)
    libmx.so => /home/speech/matlab/bin/glnx86/./libmx.so (0xb7df7000)
    libmat.so => /home/speech/matlab/bin/glnx86/./libmat.so (0xb7dee000)
    libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7db4000)
    libstdc++.so.5 =>
/home/speech/matlab/bin/glnx86/./../../sys/os/glnx86/libstdc++.so.5
(0xb7d0f000)
    libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7ce9000)
    libgcc_s.so.1 =>
/home/speech/matlab/bin/glnx86/./../../sys/os/glnx86/libgcc_s.so.1
(0xb7ce1000)
    libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7b7d000)
    librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7b74000)
    libicudata.so.24 =>
/home/speech/matlab/bin/glnx86/./libicudata.so.24 (0xb7b72000)
    libicui18n.so.24 =>
/home/speech/matlab/bin/glnx86/./libicui18n.so.24 (0xb7ab6000)
    libicuuc.so.24 => /home/speech/matlab/bin/glnx86/./libicuuc.so.24
(0xb7a1f000)
    libustdio.so.24 => /home/speech/matlab/bin/glnx86/./libustdio.so.24
(0xb7a0f000)
    libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7a0b000)
    libz.so => /home/speech/matlab/bin/glnx86/./libz.so (0xb79fc000)
    /lib/ld-linux.so.2 (0xb7ef1000)

Note the full paths - this is most likely a consequence of using rpath
when linking libeng.so. Those paths have precedence over
LD_LIBRARY_PATH. I am not sure what happens if you load libeng.so
dynamically through dlopen and co (as does ctype), and that prior to
calling, dlopen, you already have libz from /usr/lib. The ELF model is
such as any library is shared through the whole binary, and I don't know
how rpath interacts with this.

David



More information about the Scipy-dev mailing list