Date: Wed, 5 Mar 2008 21:44:57 +0100 From: "Simon L. Nielsen" <simon@FreeBSD.org> To: Chris <chrcoluk@gmail.com> Cc: FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: linked ssl libraries to binary Message-ID: <20080305204456.GA1597@zaphod.nitro.dk> In-Reply-To: <3aaaa3a0803040405l74135ea9va2ebfbe6ee0b5fc1@mail.gmail.com> References: <3aaaa3a0803040405l74135ea9va2ebfbe6ee0b5fc1@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080305204456.GA1597>