This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 3.3.5 arm-elf .. which multilib for soft-float?
On Tue, 2004-11-02 at 12:24, Joel Sherrill wrote:
> Richard Earnshaw wrote:
> > On Tue, 2004-11-02 at 00:21, Joel Sherrill wrote:
> >
> >>Hi,
> >>
> >>It looks like btween gcc 3.3.3 and 3.3.5, the file config/arm/t-arm-elf
> >>was reworked. I am getting linking errors which indicate that the
> >>default libc.a is hard-float.
> >>
> >>The gcc documentation states that -mhard-float is the default for the
> >>compiler and I only see these libc.a's
> >>
> >
> >
> > -mhard-float has *never* been the default for the arm-elf
> > configuration. In fact, AFAIK the only supported configuration of gcc
> > on ARM that still uses the FPA hard-float format is Linux.
>
> I rather suspected this because I didn't recall any RTEMS user CPU model
> I had ever looked at having hard float.
>
> But the gcc documentation states that hard-float is ALWAYS the default:
The documentation is out of date. There is a time when that was correct
for all the (then) supported configurations, but it's now far from the
truth.
> Given all that, why can't I link code when I use the -msoft-float flag.
> From your description, it is redundant but it results in a string
> of link errors like this:
>
> /../../arm-rtems4.7/bin/ld: failed to merge target specific data of file
> /opt/rtems-4.7/lib/gcc-lib/arm-rtems4.7/3.3.5/libgcc.a(_pack_sf.o)
>
> $ cat j.c
> #include <math.h>
> float f( float x)
> {
> return sin(x);
>
> }
>
> $ /opt/rtems-4.7/bin/arm-rtems4.7-gcc j.c -O2 -lm
> # WORKS
> $ /opt/rtems-4.7/bin/arm-rtems4.7-gcc -msoft-float j.c -O2 -lm
> # FAILS with ERRORS
>
Ah! I suspect you are trying to link some object compiled with
-msoft-float with objects that were compiled with neither -msoft-float
nor -mhard-float explicitly mentioned on the command line. Gas assumes
(incorrectly in this case) that if you don't specify -msoft-float you
meant -mhard-float (the compiler makes the opposite assumption, but
fails to pass on this information).
Ralf's patch should fix that issue, since it always passes something to
the assembler; but you will have to rebuild any objects built without
his patch applied.
R.