libpthread.so.2 compatibility
John Hay
jhay at meraka.org.za
Mon Jun 5 17:14:28 UTC 2006
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.
John
--
John Hay -- John.Hay at meraka.csir.co.za / jhay at FreeBSD.org
More information about the freebsd-current
mailing list