[Clfs-dev] Embedded with EGLIBC - Testers Wanted

[Andrew Bradford]

On 10/07/13 08:17, Kirk Terrell wrote:
> On 10/04/2013 08:09 AM, Andrew Bradford wrote:
>> 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.
>>
> I am holding off reporting failures since they seem to be header related
> and it appears this is a known issue - I am going to look at the
> mini-lkh package pointed to in the lists, and also try to put the musl
> headers and linux headers in separate directories.

OK, good to know.

> I'm not sure if an openembedded tutorial is a CLFS project - but if you
> managed it your praises would be sung far and wide.

Which would be sad, as I thought that was half the point of Yocto.  But
Yocto docs, as far as I can tell, are quite horrible to actually learn
anything from.  I should read them again and see if that's changed.

But true, it's not really a CLFS thing then.

> I skimmed thru an article in Linux Journal this month that was a
> tutorial on how to put the debian distribution on a different ARM board.
> Another option might be to focus on how to marry an existing
> distribution with a board to get it up and running.

Regarding putting any distro or (C)LFS onto any board, really the only
part that's board specific is the kernel and bootloader.  Beyond that,
so long as your libc and all applications are compiled for that arch,
you're set.  For instance, getting Debian onto any ARM board is quite
simple (sorry, haven't read the LJ article) once you understand how
multistrap works and you can get your kernel and bootloader setup.  The
Debian docs are quite decent and the debian-embedded ml is full of smart
people.

I run Debian Squeeze for work, on ARM.  It's not the best solution to
the problem but it works well enough and most of the hard problems are
solved, it's just implementation really.

Thanks,
Andrew