[Clfs-dev] Embedded with EGLIBC - Testers Wanted

[Andrew Bradford]

On 10/03/13 23:27, Kirk Terrell wrote:
> On 10/02/2013 10:52 AM, Rob Landley wrote:
>> 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.)
> 
> I've spent some time on using musl as a replacement in CLFS embedded
> fork. The biggest drawback is the 60/40 chance that an additional
> package will compile. I ran thru a sample of 13 packages from BLFS that
> were chosen because they used the GNU Build System and were written in C
> and had no additional prerequisites - only 8 packages compiled using the
> instructions in BLFS.

Have you reported these failures to the musl ml?  (sorry if you did and
I missed it)

> What niche is the CLFS embedded targeting - a raspPI can run a full
> blown desktop distribution?

Determining what niche is hard but is a good question.  I think CLFS's
embedded book should show how to build a busybox (or similar) based
rootfs without needing to boot or chroot (like the main CLFS book).  The
capabilities of the processor or board it ends up running on aren't that
important.

A better question, though, given that openembedded seems like the
predominant build system for doing this activity, would be should CLFS
embedded stop trying to show how to do a build like this by hand but
instead focus on teaching people how to use openembedded?  My first
impressions, both a few years ago when I looked at it and then again
recently, of openembedded or other bitbake build systems is that it's
very powerful but horribly documented on the how, why, and what happens
or how to expand it.  The learning curve for how to leverage oe/bitbake
effectively beyond just using Angstrom or similar is steep but it
doesn't need to be.

For instance, are there bitbake receipes/layers for making a
musl/busybox rootfs?  Would that be valuable?  Would a well written
documenation saying wtf is going on within the build process be useful?

Or am I off on a tangent?

I'm kind of getting burned out with CLFS embedded lately.  There's a lot
that needs to be updated and I've been getting frustrated a lot lately
by that.  There was a good year or so break in my contributions to CLFS
embedded and not much happened during that time.  The developer interest
in keeping the book up to date seems to be very low.

Thanks,
Andrew