Subject: re: Softfloat and GCC
To: matthew green <>
From: Ben Harris <>
List: tech-toolchain
Date: 09/16/2003 14:19:37
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

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                                                   <>
Portmaster, NetBSD/acorn26           <URL:>