Re: libpthread.so.2 compatibility

On Mon, 5 Jun 2006, John Hay wrote:

> On Mon, Jun 05, 2006 at 01:01:11PM -0400, Daniel Eischen wrote:
>> On Mon, 5 Jun 2006, John Hay wrote:
>>>>
>>>> How old was your system when you upgraded to -current?  There
>>>> were changes to malloc() in libc.so.6 which have been in -current
>>>> for a while, and libpthread is dependent on some internal locks
>>>> in libc.  If you are using a libc.so.6 before jasone's malloc()
>>>> changes and a newer libpthread, then that won't work.  When you
>>>> recompile, your binaries will be linked to libc.so.7, and
>>>> libpthread.so.2 will find the correct locks.  If you don't
>>>> find the following:
>>>>
>>>>  $ readelf -s /lib/libc.so.6 | grep _malloc
>>>>     275: 0005f65c   139 FUNC    GLOBAL DEFAULT    8 _malloc_postfork
>>>>     299: 000e96d0     4 OBJECT  GLOBAL DEFAULT   19 _malloc_options
>>>>     870: 0005f5d0   139 FUNC    GLOBAL DEFAULT    8 _malloc_prefork
>>>>    2486: 000d1fd8     4 OBJECT  GLOBAL DEFAULT   11 _malloc_message
>>>>
>>>> _malloc_postfork and _malloc_prefork in libc.so.6, then that is
>>>> probably why libpthread is failing.
>>>
>>> The libc.so.6 I copied from the -stable box does not have it:
>>>
>>> # readelf -s /lib/libc.so.6 | grep _malloc
>>>  281: 000d78b4     4 OBJECT  GLOBAL DEFAULT   18 _malloc_options
>>> 1705: 000c0e30     4 OBJECT  GLOBAL DEFAULT   11 __malloc_lock
>>> 2351: 000c0e2c     4 OBJECT  GLOBAL DEFAULT   11 _malloc_message
>>>
>>> But the one from the -current box has it:
>>>
>>> # readelf -s /lib/libc.so.6.old  | grep _malloc
>>>  274: 0005fcd4   113 FUNC    GLOBAL DEFAULT    8 _malloc_postfork
>>>  297: 000e25d4     4 OBJECT  GLOBAL DEFAULT   19 _malloc_options
>>>  852: 0005fc60   113 FUNC    GLOBAL DEFAULT    8 _malloc_prefork
>>> 2424: 000cae38     4 OBJECT  GLOBAL DEFAULT   11 _malloc_message
>>>
>>> Does it work for you? Can you take a 6-stable libpthread app and run
>>> it on current?
>>
>> No, you can't make a 6-stable libpthread and have it work
>> on -current.  Both libc and libpthread have to match.  There
>> were also other changes in libc that libpthread relies on
>> (__thr_jtable changed in size).
>>
>> When you upgraded to -current, you got a different libpthread
>> that is reliant on -current's libc.  But since libc's version
>> was bumped, you never got a -current libc.so.6 that was
>> compatible with libpthread.  The only way to get around this
>> is to go back a couple of weeks to before the resolver
>> changes and libc bump were committed -- rebuild libc.so.6
>> from those older sources.
>
> Not sure if I understand you wrong. I didn't mean that one should
> take a 6-stable libpthread. I meant an app that use libpthread. Or
> is that what you mean? That one cannot use an app on -current that
> use libpthread, but was compiled on 6-stable? If that was so, I
> will accept it, although the commit message in libpthread/Makefile
> ver 1.55 make it sound as if it should work.

No, you can't use that app unless you somehow build it so that
it doesn't use libc.  The problem is that you don't have a
libc.so.6 that matches libpthread.so.2.  You -stable app depends
on libc.so.6, not libc.so.7.  When you upgrade from -stable
to -current, you bypass the changes that went into libc.so.6
before it became libc.so.7.  The -current libpthread.so.2
changed to stay in sync with those changes.

Bottom line:  -stable libc.so.6 != -current libc.so.6
               -stable libpthread.so.2 != -current libpthread.so.2

Both libpthread.so.2 and libc.so.6 (and .so.7) have to be
in sync (built from same-dated sources).

-- 
DE