[En-Nut-Discussion] Runtime library dependencies
harald.kipp at egnite.de
Fri Sep 28 15:38:52 CEST 2012
On 28.09.2012 15:03, Ole Reinhardt wrote:
> Yes, I agree. We should try to keep it compatible. But in the next
> moment I'm thinking about other tools as well (Keil etc...) we don't
> have specific support for these tools yet. But it might be a good Idea
> to get in contact with these companies to get at least mentioned as
> supported OS. Unfortunately this will take some effort to make NutOS
> compatible with their tools but also might increase the user base.
May I remind you, that I was recently looking for someone, who would
have been able to respond to the request from STMicroelectronics
regarding Nut/OS support for the STM32?
Uwe was so kind to post a status to this list, but no one finally
answered STM's request. Nut/OS marketing is really lousy. ;-)
> Do we really _need_ the newlib features? I can not remember to use any
> newlib specific code, at least in the code I wrote. All functions we use
> are just "normal" libc functions. And if there is any function that is
> not yet available in our small libc implementation we could think about
> adding these specific functions as well.
You're right, in general we are not using newlib specific code.
But there is an unsolved problem with newlib's dtoa(). The issue is,
that this function uses newlib's internal malloc, which finally results
in a call to _sbrk. To solve this dependency, Nut/OS provides a
simplified crt/sbrk.c, just to please newlib.
Floating point to ASCII conversions (and vice versa) are typically not
well implemented. Newlib uses some really ancient code. I's really like
to have an independent replacement...well...24h per day is not enough.
More information about the En-Nut-Discussion