This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Building newlib without -mhard-float
- From: Dave Murphy <wintermute2k4 at ntlworld dot com>
- To: Rick Mann <rmann at latencyzero dot com>
- Cc: newlib at sourceware dot org
- Date: Wed, 05 Sep 2007 00:25:42 +0100
- Subject: Re: Building newlib without -mhard-float
- References: <355F8F45-AF50-49FA-8E41-A38A49AC5A7E@latencyzero.com>
Rick Mann wrote:
I'm having a heck of a time getting newlib variants for ARM with VFP
instructions. I configure using --with-float=soft, but it still builds
a bunch of versions using -mhard-float. I tried modifying
CFLAGS_FOR_TARGET to include -mcpu=xscale and/or -march=armv5te, but
then I get errors about it confilicting with -mhard-float.
I've been maintaining a gcc/newlib based arm cross compiler for a few
years now and in the beginning I experienced a lot of trouble with soft
vs hard float library issues. After a lot of searching and testing I
found that an arm-elf compiler produces soft-float binaries by default
but that the object files are actually marked as hard-float which, as
far as I could determine, is a legacy thing related to systems which
used FPU emulation. The only way I could get my toolchain to function as
intended was to use the default options and *not* use -msoft-float at
*any* point anywhere in the build process.
Most recently I had problems with a system which contains dual
processors, one arm7tdmi and one arm946e-s. The arm-elf toolchain
complained loudly about VFP mismatches when I tried to build code for
armv5te but obviously I wanted the libraries to be built for armv4t so
that the toolchain could still build binaries for the other supported
platforms. I asked for advice on IRC from Richard Earnshaw and some of
the other developers working with ARM and they advised me to switch to
arm-eabi which allows code for armv4t and armv5te to be mixed freely
without all the mismatching problems. It also allows for arm and thumb
code to co-exist without the need for the interworking libraries needed
with arm-elf. I've had very few problems since switching over.
The toolchain I'm maintaining is biased towards amateur game development
but is still useful as a more general ARM toolchain. The main site is at
http://www.devkitpro.org, all the buildscripts and patches I use are in
CVS at http://sourceforge.net/projects/devkitpro
My newlib patches are heavily modified to add a pseudo device API which
handles the low level stdio functions so you're probably better off
sticking with vanilla newlib and just using the buildscripts for general
guidance.
Dave