libpthread.so.2 compatibility

Daniel Eischen deischen at freebsd.org
Sun Jun 4 15:59:46 UTC 2006


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.

-- 
DE


More information about the freebsd-current mailing list