Re: multilib won't build soft-float libraries for strongarm-elf

[<tim dot klein at dsl dot pipex dot com>]

Richard,

Thanks for your message.  You are of course correct that the default compiler 
operation is to generate little endian, soft float code.  The error I'm 
guessing is that it doesn't mark the output files correctly - again I'm 
guessing that the ELF header's flags are what the linker uses to detect the 
type of floating point used, and when it sees a mismatch it gives an error.

It would still be nice to explicitly declare my choice of floating point and 
endianism at compile time and during linking via the library path. Do you or 
anyone else know why MULTILIB fails to build the variants in the 
MULTILIB_OPTIONS.  Better still, can you advise how to make it build the 
libraries using the -msoft-float -mlittle-endian compiler switches ?

Thanks,

Tim



Quoting Richard Earnshaw <rearnsha@arm.com>:

> > For some reason when I build a gcc cross for strongarm-elf using a
> cygwin
> > host I don't get the soft floating point libraries.  I don't get any
> errors
> > while building, and the croos compiler works fine, just no soft-float
> > libraries.
> > 
> > Multilib appears to be working as I get be (-mbig-endian) and fpu
> > (-mhard-float) directories populated with libraries.  I thought the
> default
> > library might be soft-float/little-endian but when I compile a c or
> c++ app
> > and then try and link it I get an error telling me that the library
> was
> > compiled for hardware FP.
> > 
> > Can anyone help me - I've read everything and tried everything I can
> but
> > just can't seem to get the expected results.  I hope the following
> > information will help.
> > 
> 
> Because of the way the compiler passes directives to the assembler and
> the 
> way that the linker checks for flags we have the situation where code 
> compiled with a compiler whose default configuration is to produce 
> soft-float code is marked as incompatible with code that is compiled
> with 
> the -msoft-float flag.  This is really a bug in gcc... (but fixing it 
> would leave a nasty backwards-compatibility problem for binary linking).
> 
> You need to check the way your compiler is configured.  Compile the 
> following to assembly and check the output:
> 
> double f()
> {
>   return 1.0;
> }
> 
> If the compiler puts the result into f0, then your configuration is
> using 
> hard-float.  If it puts the result in r0,r1 then you have a soft-float 
> compiler by default.
> 
> For the second scenario, the best thing to do is to always use the 
> compiler *without* the soft-float flag and just accept it.  For the
> former 
> case things are a bit more complex if you aren't getting those
> soft-float 
> multilibs that you want (if you are, then you can just use -msoft-float 
> all the time, including during linking and things should just work).
> 
> My understanding from a quick glance at the sources is that the 
> strongarm-elf configuration does default to soft-float, so there is no 
> need ever to specify -msoft-float on the command line; I think that
> would 
> be your best approach.
> 
> R.
> 
> 




------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com