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. 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? Instead there could be a __GI___libc_sigaction. - libc_hidden_proto(sigaction) + libc_hidden_proto(__libc_sigaction) Thanks Johannes _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc