linked ssl libraries to binary

[Simon L. Nielsen]

On 2008.03.04 12:05:22 +0000, Chris wrote:

> On freebsd 6 it picks up /usr/local ssl libaries no problem and in
> fact uses them without even haveing to specify the directory it auto
> detects them over the base ssl.  On freebsd 7 it uses the base
> libraries even when telling it to search in /usr/local.

That sounds either like there is a bug in the program build
system... it might also happen if the base system and and ports
libraries have the same version number... I never tried that as I
always use base system OpenSSL.

> So I then decided to move the binary I compiled on freebsd 6 over to
> the freebsd 7 box and when I ran ldd on the binary to my surprise it
> is using the base libraries on freebsd 7.

Note that we do not guarentee at all that you can do that.  I'm not
even sure that the .so version number in the port and in the base
system match.

> ldd on binary on freebsd 6
> 
>         libssl.so.5 => /usr/local/lib/libssl.so.5 (0x48102000)
>         libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x48143000)
>         libcrypt.so.3 => /lib/libcrypt.so.3 (0x4829f000)
>         libboost_iostreams.so => /usr/local/lib/libboost_iostreams.so
> (0x482b8000)
>         libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x482c0000)
>         libm.so.4 => /lib/libm.so.4 (0x48396000)
>         libpthread.so.2 => /lib/libpthread.so.2 (0x483ac000)
>         libc.so.6 => /lib/libc.so.6 (0x483d3000)
>         libbz2.so.2 => /usr/lib/libbz2.so.2 (0x484cb000)
>         libz.so.3 => /lib/libz.so.3 (0x484dc000)
> 
> 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)

Uhh, not good.  If you link against two versions of libc bad things
are bound to happen.  That can happen if you have a old binary which
links against a new lib... or something like that.

If you want to this to work aither compile the binary statically or
get all the 6.x libs and do some LDCONFIGPATH (or whatever the env var
is called) to make sure those libs override the 7.x libs.

>         libboost_iostreams.so => /usr/local/lib/libboost_iostreams.so (0x282c1000)
>         libbz2.so.3 => /usr/lib/libbz2.so.3 (0x284ee000)
>         libc.so.7 => /lib/libc.so.7 (0x283f3000)
>         libcrypt.so.4 => /lib/libcrypt.so.4 (0x282a8000)
>         libcrypto.so.5 => /lib/libcrypto.so.5 (0x28150000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x283d5000)
>         libm.so.5 => /lib/libm.so.5 (0x283c0000)
>         libssl.so.5 => /usr/lib/libssl.so.5 (0x2810f000)
>         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x282cc000)
>         libthr.so.3 => /lib/libthr.so.3 (0x283e0000)
>         libz.so.4 => /lib/libz.so.4 (0x284fe000)

That looks correct (at least no duplicate libs).

Unfortunatly I have no idea why it crashes on 7 naively compiled.

-- 
Simon L. Nielsen