Date: Sun, 4 Jun 2006 14:26:51 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: John Hay <jhay@meraka.org.za> Cc: current@freebsd.org Subject: Re: libpthread.so.2 compatibility Message-ID: <Pine.GSO.4.64.0606041423260.9199@sea.ntplx.net> In-Reply-To: <20060604174315.GA64158@zibbi.meraka.csir.co.za> References: <20060604075414.GA47483@zibbi.meraka.csir.co.za> <20060604082335.GB76919@over-yonder.net> <Pine.GSO.4.64.0606041043350.8207@sea.ntplx.net> <20060604153210.GA60476@zibbi.meraka.csir.co.za> <Pine.GSO.4.64.0606041156020.8602@sea.ntplx.net> <20060604174315.GA64158@zibbi.meraka.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 4 Jun 2006, John Hay wrote: >>>>> FWIW, I just upgraded a system from an early January -CURRENT, and I'm >>>>> getting the same thing. I've already rebuilt most things, which >>>>> probably means there'll be a "fix" for this that requires rebuilding >>>>> them again :p >>>> >>>> There have been no ABI changes in libpthread, so it must be coming >>>> from somewhere else. I know that libc had some ABI changes but >>>> it's version was bumped to account for that. >>>> >>>> libpthread did move from /usr/lib to /lib, but I don't know how >>>> that would bite you unless you deleted it from /usr/lib in the >>>> upgrade process. >>> >>> Ok, maybe it isn't some ABI change inside libpthread. Can it maybe be >>> that we have two "versions" of libpthread.so.2 now, one that was >>> compiled and like to be linked to libc.so.6 and one that like to be >>> linked to libc.so.7? So if you now try to run an older threaded app >>> (one that was compiled with libc.so.6 and libpthread.so.2, like what >>> would happen in FreeBSD-6) on -current, it would try to use the new >>> libpthread.so.2 that was build against libc.so.7, but try to link it >>> with libc.so.6 and then crash and burn? Maybe when libc gets bumped >>> all other libs have to be bumped too? >> >> All others have to be bumped anyway (in -current) but I don't know >> if that is what is causing the problem. ldd or readelf -d are your >> friends... If there are multiple dependencies on libpthread, then >> that is probably causing the problem. > > I have done it, but do not see anything strange. ldd looks like this, > with and without the libmap.conf tweak: [ ... ] > Actually one does not even need a big complex app to see the problem. > Just copy /sbin/ggatec from 6.1 or 6.1-stable to a current box and you > will see it happen: > > ####### > angel:~ > uname -a > FreeBSD angel.cids.org.za 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sun May 28 11:06:16 SAST 2006 jhay@angel.cids.org.za:/usr/src/sys/i386/compile/ANGEL i386 > angel:~ > ssh zibbi "uname -a" > FreeBSD zibbi.meraka.csir.co.za 6.1-STABLE FreeBSD 6.1-STABLE #4: Thu May 25 06:11:44 SAST 2006 jhay@zibbi.meraka.csir.co.za:/usr/src/sys/i386/compile/ZIBBI i386 > angel:~ > scp -p zibbi:/sbin/ggatec /tmp/ > ggatec 100% 16KB 8.1KB/s 00:02 > angel:~ > /tmp/ggatec > Segmentation fault (core dumped) > ####### It is probably the networking ABI changes in libc. There was a short period of time when there were ABI changes in libc.so.6 in -current -- before libc was bumped to libc.so.7. What happens when you try moving a -stable libc.so.6 to the -current machine? -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0606041423260.9199>