Date: Mon, 5 Jun 2006 13:01:11 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: John Hay <jhay@meraka.org.za> Cc: current@freebsd.org Subject: Re: libpthread.so.2 compatibility Message-ID: <Pine.GSO.4.64.0606051253280.14745@sea.ntplx.net> In-Reply-To: <20060605164711.GA8065@zibbi.meraka.csir.co.za> References: <20060604075414.GA47483@zibbi.meraka.csir.co.za> <20060604082335.GB76919@over-yonder.net> <Pine.GSO.4.64.0606041043350.8207@sea.ntplx.net> <20060604153210.GA60476@zibbi.meraka.csir.co.za> <Pine.GSO.4.64.0606041156020.8602@sea.ntplx.net> <20060604174315.GA64158@zibbi.meraka.csir.co.za> <Pine.GSO.4.64.0606041423260.9199@sea.ntplx.net> <20060604191000.GA67836@zibbi.meraka.csir.co.za> <Pine.GSO.4.64.0606041902230.10482@sea.ntplx.net> <Pine.GSO.4.64.0606041914530.10482@sea.ntplx.net> <20060605164711.GA8065@zibbi.meraka.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0606051253280.14745>