This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Building newlib without -mhard-float


Rick Mann wrote:

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?


That would be my starting point.


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]