On 27/01/2012 14.17, Carmelo AMOROSO wrote:
> 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)
>
So, to summarise I'd expect
libc.{so,a}
---> __libc_sigaction (global)
---> __GI_sigaction (hidden alias for internal use)
---> sigaction
a. A wrapper to __libc_sigaction (if NPTL configured)
b. A weak alias to __libc_sigaction (thread none)
and nothing duplicated into libpthread.
make more sense ?
carmelo
> 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@uclibc.org
>> http://lists.busybox.net/mailman/listinfo/uclibc
>>
>
> _______________________________________________
> uClibc mailing list
> uClibc@uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
>
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
