On Fri, Mar 25, 2011 at 6:33 PM, Peter Mazinger <p...@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? _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
