Building newlib without -mhard-float

Rick Mann rmann@latencyzero.com
Wed Sep 5 20:16:00 GMT 2007


On Sep 5, 2007, at 12:27 PM, Jeff Johnston wrote:

> My suggestion would be to back off this idea and simply build gcc  
> and newlib without tinkering (disabling multilib and using  
> TARGET_CFLAGS is tinkering).  This should give you all the possible  
> arm-elf permutations and the various libraries will be in sync  
> (i.e. newlib generated code won't reference any function that isn't  
> found in libc/libm, libgloss, or libgcc).  Then, try and find one  
> set of options that works for your target platform (e.g. arm-elf- 
> gcc -g -mcpu=xscale -msoft-float test.c).  If none of the  
> permutations work, then it means you need to add one to gcc's list  
> so that you get a libgcc and newlib/libgloss that are in sync and  
> use the options you want.  Adding a multilib is straightforward and  
> has been done before.

Okay. That brings up the stage 1/2 approach someone else suggested I  
use. A more recent post suggested I not do that, but I wanted to get  
confirmation.

Since I need to rebuilt GCC (to enable multilib), I want to know: Can  
I just build, *from scratch*, binutils, gcc, and then build newlib?  
Or will I face some obstacles in doing so? That is, can I delete (or  
hide) my existing /usr/local/arm directories and build everything in  
one pass?

When I build things, should I limit myself to --target=arm-elf and -- 
with-newlib?

I'll try this, but I'm not sure it will work. However, the thing that  
originally motivated so much of this (getting VFP into all the built  
pieces because of a single lib.a that I couldn't rebuild) may not be  
a problem much longer.


Thanks!

-- 
Rick




More information about the Newlib mailing list