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