On Tue, 16 Sep 2003, matthew green wrote:

>
>    >. when I tried to build sh3 libc with -DSOFTFLOAT_NEED_FIXUNS
>    >  I've got linkage conflicts while building gprof
>    >
>    >/usr/nb/distrib/hpcsh/usr/lib/libc.a(softfloat.o): In function `__fixunsdfsi':
>    >softfloat.o(.text+0x257c): multiple definition of `__fixunsdfsi'
>    >/usr/nb/distrib/hpcsh/usr/lib/libgcc.a(_fixunsdfsi.o)(.text+0x0): first defined here
>    >/usr/nb/tools/shle--netbsdelf/bin/ld: Warning: size of symbol `__fixunsdfsi' changed from 100 to 220 in /usr/nb/distrib/hpcsh/usr/lib/libc.a(softfloat.o)
>
>    So that considers that libgcc version to be "first", and then explodes on
>    the libc one.  As I understand it, the tail of the linker invocation goes
>    something like "-lc -lgcc -lc", so what's happened here is that the main
>
> looking at "gcc -v" output, that's "-lgcc -lc -lgcc".

Oops.  Serves me right for not checking.  In that case, something in the
main program used __fixunsdfsi, which uses __fixdfsi, which pulls in
softfloat.o from libc, which tries to redefine __fixunsdfsi, which causes
doom.

This suggests that if there's anything that's implemented in both libc and
libgcc then the only time the libc version will be used (in a static
executable) is when it's used by libc and nothing in the application has
used it.  This seems really rather ugly to me.  Maybe I should try to
understand how it works for dynamic executables, though I suspect that
will make my head hurt.

-- 
Ben Harris                                                   <bjh21@NetBSD.org>
Portmaster, NetBSD/acorn26           <URL:http://www.NetBSD.org/Ports/acorn26/>