Building newlib without -mhard-float

[Jeff Johnston]

Rick Mann wrote:
> I seem to be getting closer with newlib. I've succeeded in writing code 
> that calls memcpy and memset, and running that on the target hardware. 
> Now I'm trying to get sprintf() to work, with less success.
> 
> The biggest problem is that a great many floating point functions don't 
> appear to be defined. So, I tried siprintf(), the integer version, and 
> now I just get a couple of undefined integer routines:
> 
> /Users/rmann/Desktop/gcc/newlib-1.15.0/build2/arm-elf/newlib/libc/stdio/../../../../../newlib/libc/stdio/vfprintf.c:1135: 
> undefined reference to `__umoddi3'
> /Users/rmann/Desktop/gcc/newlib-1.15.0/build2/arm-elf/newlib/libc/stdio/../../../../../newlib/libc/stdio/vfprintf.c:1136: 
> undefined reference to `__udivdi3'
> 

These are in the gcc lib: libgcc.a  You need to add a -lgcc at the end 
of your compile/link.  If the compiler was built multilib, you will need 
to specify the options you used to build newlib with (e.g. -march=x 
-mcpu=y) as the compiler will match up a multilib libgcc.a with those 
options.  If you are using ld directly, you will have to point to the 
appropriate subdirectory to find the right libgcc.a.

> 
> Of course, I currently also don't have defined things like _sbrk_r(), 
> but I realize that's because I have a bare-bones build, and need to 
> provide those myself.
> 

These are provided by libgloss.  Check out libc/include/reent.h for 
details on how you can supply syscalls.  Also note there is a default 
libgloss library: libnosys provided (-lnosys) which has stubs for just 
about everything, but does include an sbrk implementation, assuming you 
set up a heap boundary below your stack (the external value "end").  You 
would still need an _exit call which can be an exception-causing event 
or a trap call).

> But, can anyone advise me on where I'm going wrong with the 
> floating-point and longlong support?
> 

You'll have to explain a bit more about what actual problems you're seeing.

> Thanks ever so much!
> 
> --Rick
>