static link with NPTL on ARM fails

[Carmelo AMOROSO]

On 27/01/2012 15.55, Johannes Stezenbach wrote:
> On Fri, Jan 27, 2012 at 02:17:25PM +0100, Carmelo AMOROSO wrote:
>> 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.
> 
> Sounds good, but one question: When libc internally calls sigaction
> and libpthread is also linked, which one should be called?
> 
> I would think it should call the pthread version. 

frankly not sure. In the current implementation, when pthread are
enabled at build time (even if not used at runtime), the implementation
is taken from the pthread directory. So it should work as you expect.

Indeed, I'm thinking that there is not need at all to duplicate the
symbol into the pthread library, as the libc implementation is already
properly handling SIGCANCEL/SIGSETXID.

So, likely we should get rid of pt-sigaction.c... simply.


> If libc wants
> to call the libc version it would use __libc_sigaction explicitly.
> 
> However, with libc_hidden_proto(sigaction) in signal.h, libc
> would end up calling __GI_sigaction which is the libc version, isn't it?
> 

yes

> Instead there could be a __GI___libc_sigaction.
> 
> - libc_hidden_proto(sigaction)
> + libc_hidden_proto(__libc_sigaction)
> 
> 
> Thanks
> Johannes
> 

carmelo