Building newlib without -mhard-float

[Rick Mann]

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.

  2a8:	e3a035ff 	mov	r3, #1069547520	; 0x3fc00000
  2ac:	e3a01101 	mov	r1, #1073741824	; 0x40000000
  2b0:	e283370e 	add	r3, r3, #3670016	; 0x380000
  2b4:	e3a04000 	mov	r4, #0	; 0x0
  2b8:	e2811601 	add	r1, r1, #1048576	; 0x100000
  2bc:	e3a02000 	mov	r2, #0	; 0x0
  2c0:	e58d3038 	str	r3, [sp, #56]
  2c4:	e58d403c 	str	r4, [sp, #60]
  2c8:	e58d1030 	str	r1, [sp, #48]
  2cc:	e58d2034 	str	r2, [sp, #52]
  2d0:	e28d0038 	add	r0, sp, #56	; 0x38
  2d4:	e8900003 	ldm	r0, {r0, r1}
  2d8:	e28d2030 	add	r2, sp, #48	; 0x30
  2dc:	e892000c 	ldm	r2, {r2, r3}
  2e0:	ebfffffe 	bl	0 <__muldf3>
  2e4:	ebfffffe 	bl	0 <__fixdfsi>


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