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] |
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.
-- Rick
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |