> >>>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.orgReceived on Sun Jun 04 2006 - 15:43:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:56 UTC