libpthread.so.2 compatibility
John Hay
jhay at meraka.org.za
Sun Jun 4 17:43:21 UTC 2006
> >>>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:
#########
angel:~ > ldd /usr/local/diablo-jdk1.5.0/bin/javac
/usr/local/diablo-jdk1.5.0/bin/javac:
libz.so.3 => /lib/libz.so.3 (0x2808e000)
libpthread.so.2 => /lib/libpthread.so.2 (0x2809f000)
libc.so.6 => /lib/libc.so.6 (0x280c4000)
angel:~ > ldd /usr/local/diablo-jdk1.5.0/bin/javac
/usr/local/diablo-jdk1.5.0/bin/javac:
libz.so.3 => /lib/libz.so.3 (0x2808e000)
libpthread.so.2 => /lib/libpthread.old.so.2 (0x2809f000)
libc.so.6 => /lib/libc.so.6 (0x280c4000)
#########
readelf -d /lib/libpthread.so.2 also doesn't show anything strange...
I think:
#######
Dynamic segment at offset 0x204dc contains 20 entries:
Tag Type Name/Value
0x0000000e (SONAME) Library soname: [libpthread.so.2]
0x0000000c (INIT) 0x4c0c
0x0000000d (FINI) 0x1e944
0x00000004 (HASH) 0x94
0x00000005 (STRTAB) 0x2a88
0x00000006 (SYMTAB) 0xc48
0x0000000a (STRSZ) 4620 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000003 (PLTGOT) 0x205b4
0x00000002 (PLTRELSZ) 912 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x487c
0x00000011 (REL) 0x40cc
0x00000012 (RELSZ) 1968 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffc (VERDEF) 0x405c
0x6ffffffd (VERDEFNUM) 4
0x6ffffff0 (VERSYM) 0x3c94
0x6ffffffa (RELCOUNT) 50
0x00000000 (NULL) 0x0
#######
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 at 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 at 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)
#######
John
--
John Hay -- John.Hay at meraka.csir.co.za / jhay at FreeBSD.org
More information about the freebsd-current
mailing list