porting uClibc to a new arch
Bernhard Reutner-Fischer
rep.dot.nop at gmail.com
Wed Jun 3 09:45:27 UTC 2009
On Wed, Jun 03, 2009 at 10:02:47AM +0200, Ricard Wanderlof wrote:
>
> On Wed, 3 Jun 2009, Florent DEFAY wrote:
>
>> I am working on a toolchain for a new arch.
>> We already ported binutils, GCC and Newlib.
>>
>> This is an embedded micro-controller. There is no OS because we don't need one.
>> We are interested particularly in printf and scanf, which Newlib can do.
>>
>> The problem is that program linked with Newlib calling printf are too
>> large. The target is 16 bit and RAM is addressed on 16 bit. We thought
>> that replacing Newlib by uClibc could solve the problem.
>
> Without any research into the matter, I would think that uClibc would be
> larger than Newlib. To my mind, uClibc is geared towards the larger end
> of the embedded market, i.e. 32-bit processors with MMU's (even if there
> are exceptions), megabytes of memory etc, whereas Newlib is intended to
> be small. Also uClibc is really designed as a small-scale replacement to
> glibc which in turn is geared towards Linux. There are exceptions, but
Given that you can turn off most if not all those linux-specific things and
can configure uClibc down to way below 100k on-disk footprint and that mjn
use(d) uClibc on some 16bit platform i tend to think that uClibc should
be useful on small devices also.
There was once a patch that added libgloss support for uClibc. I certainly
support any attempt to add libgloss(-like) targets.
> that's the general direction.
One advantage of uClibc is configurability, both up and down.
More information about the uClibc
mailing list