[Clfs-dev] Embedded with EGLIBC - Testers Wanted

[Rob Landley]

On 10/01/2013 10:11:03 PM, Andrew Bradford wrote:
> 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.

One of the things that attracts me to uClibc and musl is you don't need  
perl as a build prerequisite for either. I pushed patches upstream to  
linux to take out the perl build prerequisite that appeared in 2.6.25  
(as of 3.10 or so it's gone away again), so if you're using a libc  
other than glibc, perl can move from LFS to BLFS.

Also, size isn't my only criteria, I like the simplicity of musl. If  
somebody wants to security audit their system, it's a lot easier to  
read through the whole of musl than to read and understand all the  
glibc code. (uClibc... less so than it used to be.)

Rob