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