On Sun, 4 Jun 2006, John Hay wrote: > On Sun, Jun 04, 2006 at 10:46:00AM -0400, Daniel Eischen wrote: >> On Sun, 4 Jun 2006, Matthew D. Fuller wrote: >> >>> On Sun, Jun 04, 2006 at 09:54:14AM +0200 I heard the voice of >>> John Hay, and lo! it spake thus: >>>> >>>> They all seem to die in pthread_setcancelstate according to gdb: >>> >>> 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. -- DEReceived on Sun Jun 04 2006 - 13:59:45 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:56 UTC