static link with NPTL on ARM fails

[Johannes Stezenbach]

On Mon, Nov 28, 2011 at 10:51:04PM +0100, Bernhard Reutner-Fischer wrote:
> On Nov 28, 2011 6:43 PM, "Johannes Stezenbach" <js at sig21.net> wrote:
> >
> > I'm in the process of building a toolchain with crosstool-ng,
> > with uClibc-0.9.32 + NPTL for ARM926EJ-S.
> >
> > Trying to statically link a simple testcase with NPTL fails:
> >
> > $ cat t.c
> > #include <pthread.h>
> >
> > int main(int argc, char *argv[])
> > {
> >        return (int)pthread_create;
> > }
> > $ arm-linux-gcc -Wall -Os t.c -lpthread -static -Wl,-Map=m
> >
> /tmp/tc/arm-unknown-linux-uclibcgnueabi/arm-unknown-linux-uclibcgnueabi/sysroot/usr/lib/libc.a(sigaction.o):
> In function `__libc_sigaction':
> > sigaction.c:(.text+0x0): multiple definition of `__libc_sigaction'
> >
> /tmp/tc/arm-unknown-linux-uclibcgnueabi/arm-unknown-linux-uclibcgnueabi/sysroot/usr/lib/libpthread.a(pt-sigaction.o):pt-sigaction.c:(.text+0x0):
> first defined here
> 
> Can you reproduce this with current master?

Yes.  I get exactly the same failure.

A general question:  What is the purpose of enabling the __GI_ internal
aliases for static objects?  According to the comment in libc-symbols.h,
hidden_proto() etc. are for PLT bypassing.

I'm trying to figure out this is all supposed to work, thus a few
statements with lots of question marks.  Please let me know
if this makes sense:


There could be two reasons for PLT bypassing:
1. performance (less work for ld.so since the linker can resolve these statically)
2. correctness (even if e.g. libpthread overrides a symbol libc still needs
   to call its own version)

I'm not sure if there are actual cases for reason 2?

For the sigaction issue it looks wrong to me that abort() calls __GI_sigaction
and not the NPTL version.  FWIW, glibc does not have libc_hidden_proto(sigaction),
but only libc_hidden_proto(__sigaction) and libc_hidden_proto(__libc_sigaction).

I.e. if libc wants to refer explicitly to the libc version of a function,
not to the NPTL version, it would refer to __libc_*, and not rely on
the libc_hidden_proto magic.  IOW, the libc_hidden_proto magic is only
for performance, not for correctness?



Thanks
Johannes