Jason Thorpe <thorpej@wasabisystems.com> writes:

> On Tuesday, September 16, 2003, at 06:19  AM, Ben Harris wrote:
> 
> > 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.
> 
> I think we need to make sure that the libgcc never contains softfloat.
> The softfloat in our libc is better than libgcc's (for one, it
> supports the basic FP exception stuff).
> 
> I remember doing this for the SH target in GCC 3.x, but we should
> probably make a sweep through all of the GCC configurations.

In that case, the fact that the floating point routines were removed
from NetBSD libgcc on the SH is causing this problem.

The original bug report was for __fixunsdfsi on the SH.  __fixunsdfsi
is defined in libgcc2, not libgcc1.  That means that it will always be
included in libgcc.

__fixunsdfsi is also included in softfloat, and it is included in a .o
file which defines many other symbols.

So there is a clear potential for conflict.  Code is linked with -lgcc
-lc -lgcc.  If the code needs __fixunsdfsi, it will be linked from
libgcc.  Other floating point support won't be there on the SF.  It
will instead come from softfloat.c.  Since softfloat.c also defines
__fixunsdfsi, we get the conflict.

Either softfloat.c must be modified to put this and similar functions
in a separate .o file, or __fixunsdfsi and similar functions must be
removed from softfloat.c, or they must be removed from NetBSD builds
of libgcc.  (I don't think there is currently any mechanism for the
latter.)

Ian