[Clfs-dev] Embedded with EGLIBC - Testers Wanted

[Andrew Bradford]

On 07/18/13 15:11, Andrew Bradford wrote:
> On Mon, Jul 15, 2013, at 08:15 AM, Andrew Bradford wrote:
>> I've not done any testing yet but I have a branch that uses EGLIBC
>> instead of uClibc for the embedded book.  If anyone wants to give it a
>> whirl and let me know what issues you find, that'd be awesome!
>>
>> I'll be doing some testing real soon now.
>>
>> https://github.com/bradfa/clfs-embedded/tree/eglibc-n-headers

That branch is a dead end but the concept is living on again for me!

> So I'm giving up on EGLIBC or glibc.  They're both huge and that's not
> really in line with the goals of the embedded book.  For now uClibc
> makes the most sense but I'm not completely ruling out musl-libc until I
> try it at least once.

glibc isn't as horrible as first thought, size wise.  It's still not as
small as uClibc can be or as musl is, but that's OK I think as the
overhead of configuring it is very low and binutils + gcc don't need any
special patches to support it.  Low overhead and straight forward
configuration win in my mind, still.

On glibc 2.18, with -Os optimizations, total size of all files placed
into ${CLFS}/lib is 15 MB.  Of that, 7.2 MB is just iconv/gconv which,
pardon me, seems useless but I need to learn more about these.  Looking
just at .so libs, libc-2.18.so is 1.4 MB and libm-2.18.so is 475 kB.
Most of the other libs are well under 100 kB with just a few things
right around 100 kb.  This isn't horrible like I expected and is quite
promising.

In addition, size of libs isn't that huge of a deal for most of the
popular systems the embedded book would target today.  GBs of flash and
hundreds of MB of ram are easy to find on armv6 or armv7-a boards today
like Rasp Pi or BeagleBone (embedded doesn't mean tiny anymore, it
seems).  Spending a few MB on glibc doesn't seem like a deal breaker to
me at this point.

What do you think?

Thanks,
Andrew