static linking failed with sigaction testing program

Kevin Cernekee cernekee at gmail.com
Sun Mar 27 01:24:33 UTC 2011


On Fri, Mar 25, 2011 at 6:33 PM, Peter Mazinger <ps.m at gmx.net> wrote:
> I assume you are using NPTL as threads, NPTL devs, one of the __sigactions needs probably be weak

<snip>

> I would say, do not use that syntax, the compiler defaults should be correct (speak, -lc is added at the end of linking, if any earlier
> __sigaction was seen in a library provided on command line by
> -l<library>, libc should provide a weak to not conflict

<snip>

> To really fix it, we have to get rid of all duplicated *sigactions, only one should stay (preferably in libc IMHO)

Since my glibc-based host PC has no problem compiling the test program
regardless of the link order, I checked to see how glibc implements
the symbol types:

libc.a: sigaction.o:
0000000000000220 T __sigaction
0000000000000220 W sigaction

libpthread.a: sigaction.o:
0000000000000220 T __sigaction
0000000000000220 W sigaction

What is the general consensus on how closely uClibc should try to
mirror glibc on these sorts of issues?  Is it worth figuring out what
they did differently?


More information about the uClibc mailing list