Date: Wed, 5 Mar 2008 05:23:15 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Jeremy Chadwick <koitsu@freebsd.org> Cc: Chris <chrcoluk@gmail.com>, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: linked ssl libraries to binary Message-ID: <20080304182315.GF90593@server.vk2pj.dyndns.org> In-Reply-To: <20080304131802.GA89947@eos.sc1.parodius.com> References: <3aaaa3a0803040405l74135ea9va2ebfbe6ee0b5fc1@mail.gmail.com> <20080304131802.GA89947@eos.sc1.parodius.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--HnQK338I3UIa/qiP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 >>=20 >> libssl.so.5 =3D> /usr/lib/libssl.so.5 (0x28101000) >> libcrypto.so.5 =3D> /lib/libcrypto.so.5 (0x28142000) >> libcrypt.so.3 =3D> /usr/local/lib/compat/libcrypt.so.3 (0x2829a0= 00) >> libboost_iostreams.so =3D> /usr/local/lib/libboost_iostreams.so = (0x282b2000) >> libstdc++.so.5 =3D> /usr/local/lib/compat/libstdc++.so.5 (0x282b= d000) >> libm.so.4 =3D> /usr/local/lib/compat/libm.so.4 (0x28388000) >> libpthread.so.2 =3D> /usr/local/lib/compat/libpthread.so.2 (0x28= 39e000) >> libc.so.6 =3D> /usr/local/lib/compat/libc.so.6 (0x283c3000) >> libc.so.7 =3D> /lib/libc.so.7 (0x284a9000) >> libbz2.so.3 =3D> /usr/lib/libbz2.so.3 (0x285a4000) >> libz.so.4 =3D> /lib/libz.so.4 (0x285b4000) >> libstdc++.so.6 =3D> /usr/lib/libstdc++.so.6 (0x285c6000) >> libm.so.5 =3D> /lib/libm.so.5 (0x286ba000) >> libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x286cf000) >> libthr.so.3 =3D> /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. Agreed. --=20 Peter Jeremy 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. --HnQK338I3UIa/qiP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHzZOT/opHv/APuIcRAlI2AKC9rHY2q9Ljr5KBhTzrGyTApNwt6QCfce5c 2dcp3bNRWWQRwCA1FQCghR0= =9C1a -----END PGP SIGNATURE----- --HnQK338I3UIa/qiP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080304182315.GF90593>