linked ssl libraries to binary
peterjeremy at optushome.com.au
Tue Mar 4 18:23:18 UTC 2008
On Tue, Mar 04, 2008 at 05:18:02AM -0800, Jeremy Chadwick wrote:
>On Tue, Mar 04, 2008 at 12:05:22PM +0000, Chris wrote:
>This doesn't come as much of a surprise. The binary actually references
>libraries by names such as libXXX.so, not libXXX.so.NUMBER.
This is incorrect. The binaries directly reference libXXX.so.NUMBER
as reported using the first column of ldd output.
>> ldd on same binary on freebsd 7
>> libssl.so.5 => /usr/lib/libssl.so.5 (0x28101000)
>> libcrypto.so.5 => /lib/libcrypto.so.5 (0x28142000)
>> libcrypt.so.3 => /usr/local/lib/compat/libcrypt.so.3 (0x2829a000)
>> libboost_iostreams.so => /usr/local/lib/libboost_iostreams.so (0x282b2000)
>> libstdc++.so.5 => /usr/local/lib/compat/libstdc++.so.5 (0x282bd000)
>> libm.so.4 => /usr/local/lib/compat/libm.so.4 (0x28388000)
>> libpthread.so.2 => /usr/local/lib/compat/libpthread.so.2 (0x2839e000)
>> libc.so.6 => /usr/local/lib/compat/libc.so.6 (0x283c3000)
>> libc.so.7 => /lib/libc.so.7 (0x284a9000)
>> libbz2.so.3 => /usr/lib/libbz2.so.3 (0x285a4000)
>> libz.so.4 => /lib/libz.so.4 (0x285b4000)
>> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x285c6000)
>> libm.so.5 => /lib/libm.so.5 (0x286ba000)
>> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x286cf000)
>> libthr.so.3 => /lib/libthr.so.3 (0x286da000)
Based on the above, the binary has direct references to (eg)
libssl.so.5 (which is found in the base system on 7.x and therefore
has embedded references to libc.so.7) and libcrypt.so.3 (which is a
6.x library and therefore has embedded references to libc.so.6).
>two linked in-versions of libc, libm, libstdc++, and others. It's
>possible this is "normal", but it seems like it would cause a crash.
This is very much abnormal and having an executable pull in two versions
of a system library virtually guarantees that it won't work.
>I indirectly answered this in my 2nd paragraph. Welcome to the UNIX
>equivalent of "DLL Hell" on Windows -- and why you should *always*
>recompile programs when the major version of a shared library (.so)
>changes. I cannot stress this enough.
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080304/73286cb9/attachment.pgp
More information about the freebsd-stable