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



On Sep 6, 2007, at 5:06 PM, Rick Mann wrote:


Here's another odd thing I'm seeing. With my current build of the tools & multilib (using --target=arm-elf and --with-cpu=xscale), if I write single- and double-precision floating point code like this:

	volatile double a = 1.5;
	volatile double b = 4.0;
	int c = (int) (a * b);

The compiler generates calls to __muldf3() and the like and everything links and executes fine.

[...]

But, if I call sprintf(), the linker complains about routines like __muldf3 (and many others) not being found:


/usr/local/arm3/lib/gcc/arm-elf/4.2.1/../../../../arm-elf/lib/libc.a (lib_a-dtoa.o): In function `_dtoa_r':
/Users/rmann/Desktop/gcc2/newlib-1.15.0/build/arm-elf/newlib/libc/ stdlib/../../../../../newlib/libc/stdlib/dtoa.c:463: undefined reference to `__muldf3'


Even more interesting, if I leave in my own floating-point code, that reference in _dtoa_r to __muldf3 is linked fine. If I remove my own floating-point code, the error comes back. It seems that GCC is unable to link the floating-point math calls in libc.a on its own, but me making reference to them in my main() makes it okay.

Well, I feel kinda dumb. I moved the -lgcc to the end of my list, and it links okay now (I still need to fill in the low-level stubs, but the floating-point is doing much better now. I wonder how long that simple change has been an issue.


I'm also not sure why putting -lgcc last makes a difference, but I guess I remember reading something about bidirectional references requiring the libraries to be listed multiple times.

Back in my glorious past, using CodeWarrior, you could control the link order by rearranging the files in the "Link" pane of the project window. Such reordering did NOT affect whether or not symbols were found, and CW was significantly faster than GCC.

OTOH, I wouldn't be able to do PXA320 development on my Mac with CodeWarrior, so I'm glad I have GCC.

--
Rick


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