ARM NPTL support for uClibc

David Daney ddaney at avtrex.com
Fri Aug 25 17:21:22 UTC 2006


Peter S. Mazinger wrote:
> On Fri, 25 Aug 2006, David Daney wrote:
> 
> 
>>Peter S. Mazinger wrote:
>>
>>>Hello!
>>>
>>>Is there no way to get rid of the libgcc_s.so dependency, the uClibc-nptl 
>>>branch seems not to need it.
>>>
>>
>>Can you get a linker map and see what the cause of the libgcc_s.so 
>>dependency is?
>>
>>David Daney.
> 
> 
> I do not know if it is related, but in uClibc++ we import libgcc_eh.a 
> content to libuClibc++.so and since gcc-4.x a symbol crept in (do not 
> have gcc sources handy, it is something starting with 3 underscores and 
> probably TLS related), so that Garrett had to link against ld-linux.so.2 
> too, (we have --as-needed -lgcc_s --no-as-needed and depending on some config 
> options libgcc_s is linked against too) but uClibc's ldso does not provide
> that symbol so he needed some workaround (as a config option UCLIBCXX_HAS_TLS) 
> to get it build on uClibc. The problem does not occur with gcc-3.4.x.
> 
> I assume that the arm NPTL port uses gcc>=4.1 (as mips does), iirc these 
> archs do not have (proper) TLS support in gcc<4.0.
> 
> We should really get rid of this dependency, how will you tell users, 
> install libgcc_s.so from gcc that you used to build and do not dare to 
> downgrade it? Or will we install libgcc_s.so without user interaction and 
> hope for the best?
> 

There also seems to be a bug in (at least) the mips linker when 
configured for uClibc (non-NPTL) where an erroneous dependency 
libgcc_s.so is often created.

I keep meaning to find and fix the problem...

David Daney.



More information about the uClibc mailing list