libpthread.so.2 compatibility

[John Hay]

> >>>
> >>>>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)
> >>>>#######
> >>>
> >>>It is probably the networking ABI changes in libc.  There was a short 
> >>>period
> >>>of time when there were ABI changes in libc.so.6 in -current -- before 
> >>>libc
> >>>was bumped to libc.so.7.  What happens when you try moving a -stable
> >>>libc.so.6
> >>>to the -current machine?
> >>
> >>Ok, I did that but it still core dump in pthread_setcancelstate()
> >
> >I don't know then.  If recompiling it fixes the problem, then
> >something in /usr/include changed.  All the pthread_foo_t types
> >are pointers to things allocated by the library, and I don't
> >think any of them changed anyways.
> 
> 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?

John
-- 
John Hay -- John.Hay at meraka.csir.co.za / jhay at FreeBSD.org