From owner-freebsd-stable@FreeBSD.ORG Wed Mar 5 21:04:15 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 458FA106567A for ; Wed, 5 Mar 2008 21:04:15 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.freebsd.org (Postfix) with ESMTP id B4D208FC18 for ; Wed, 5 Mar 2008 21:04:14 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id 984121E8C1B; Wed, 5 Mar 2008 20:44:45 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 5983011492; Wed, 5 Mar 2008 21:44:57 +0100 (CET) Date: Wed, 5 Mar 2008 21:44:57 +0100 From: "Simon L. Nielsen" To: Chris Message-ID: <20080305204456.GA1597@zaphod.nitro.dk> References: <3aaaa3a0803040405l74135ea9va2ebfbe6ee0b5fc1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3aaaa3a0803040405l74135ea9va2ebfbe6ee0b5fc1@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD Stable Subject: Re: linked ssl libraries to binary X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 21:04:15 -0000 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