static link with NPTL on ARM fails
Carmelo AMOROSO
carmelo.amoroso at st.com
Fri Jan 27 13:17:25 UTC 2012
On 27/01/2012 12.13, Carmelo AMOROSO wrote:
> On 26/01/2012 17.08, Johannes Stezenbach wrote:
>> On Fri, Jan 13, 2012 at 10:38:57AM +0100, Carmelo AMOROSO wrote:
>>> On 16/12/2011 18.36, Johannes Stezenbach wrote:
>>>> On Fri, Dec 16, 2011 at 05:59:16PM +0100, Carmelo Amoroso wrote:
>>>>> On 16/12/11 15:57, Johannes Stezenbach wrote:
>>>>>> I was able to fix the issue like this:
>>>>>>
>>>>>> --- uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c.orig 2011-12-03 18:55:45.000000000 +0100
>>>>>> +++ uClibc-0.9.33/libpthread/nptl/sysdeps/pthread/sigaction.c 2011-12-14 11:48:52.000000000 +0100
>>>>>> @@ -38,9 +38,9 @@
>>>>>>
>>>>>> return __libc_sigaction (sig, act, oact);
>>>>>> }
>>>>>> -libc_hidden_proto(sigaction)
>>>>>> +hidden_proto(sigaction)
>>>>>> weak_alias (__sigaction, sigaction)
>>>>>> -libc_hidden_weak(sigaction)
>>>>>> +hidden_weak(sigaction)
>>>>>>
>>>>>> #else
>>>>>>
>>>> ...
>>>
>>> I have now some free time to look at pending patches. It's on my queue.
>>
>> I don't want to nag, but since I just had some time to work on my
>> ARM toolchain crosstool-ng build I thought to let you know that
>> with yesterday's git eb72efd this issue is still present.
>>
>> Johannes
>>
> Hello,
> I don't think this fix is the best one; is rather a w/a.
> I'm reviewing the code as it seems we have a mess with sigaction
> symbols/aliased between libc and libpthread.
>
>
Carmelo
>
Well,
what I'd expect to have for sigaction is:
libc.{so,a}
---> __libc_sigaction (global)
---> sigaction (weak alias of __libc_sigaction)
---> __GI_sigaction (hidden alias for internal use, if any)
and
libpthread.{so,a}
---> sigaction (global)
---> __libc_sigaction (undefined)
where the sigaction implementation in the libpthread should wrap around
the __libc_sigaction adding the extra check for the SIGCANCEL and SIGSETXID.
I would not expect to see, as we currently have, __libc_sigaction
reimplemented in the pthread library.
So rather then working around the static build issue, I'd prefer to tidy
things up, definitely.
Feedback are welcome.
Carmelo
_______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
>
More information about the uClibc
mailing list