Looks like threading is b0rken on FreeBSD/powerpc
deischen at freebsd.org
Sat Aug 5 01:32:38 UTC 2006
On Sat, 5 Aug 2006, David Xu wrote:
> On Friday 04 August 2006 10:47, Wesley Morgan wrote:
>> On Wed, 2 Aug 2006, Maxim Sobolev wrote:
>>> Peter Grehan wrote:
>>>>> #0 0x2183f7b4 in tls_get_addr_common (dtvp=0x1a31490, index=2,
>>>>> offset=4294934528) at rtld.c:2663
>>>>> #1 0x218397f8 in __tls_get_addr (ti=0x21bbf0e8) at
>>>> I think you might want to try point libpthread at libthr with
>>>> libmap.conf. TLS is known to work for that where I don't think it works
>>>> for libpthread.
>>> But libpthread works in 6.0. What's the difference?
>> FWIW, recently csup stopped working for me in -current on i386. It fails
>> when checking the errno set after calling access() to check if a file
>> Updater failed: Cannot create directories leading to
>> "/usr/ports/science/p5-Algorithm-SVMLight/Makefile": Unknown error: 0
>> According to gdb, errno is being set correctly but changes almost
>> immediately back to zero. Not sure how/why, and I'm not sure that I'm even
>> using gdb correctly for threaded applications. Switching to libthr with
>> libmap.conf results in the same error.
>> I swear that it had something to do with turning on symbol versioning, but
>> attempting to turn it back off was not a fun experience and didn't have
>> the patience to see it through.
> libthr does not have mutliple versioning, the hack in libpthread is
> rather dirty, there is a plan to bump libthr version when symbol versioning
> is enabled and get rid of LIBTHREAD_1_0 symbol, it should only exist
> in libthr.so.2, libthr.so.3 will not have it.
Yes, there is a hack in libpthread that was necessary in order to
enable symbol versioning for libc. It can and will be removed
once all the necessary libraries have been bumped in preparation
for the release of 7.0.
More information about the freebsd-current