[Clfs-dev] Embedded with EGLIBC - Testers Wanted

[Kirk Terrell]

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.
>
> Thanks,
> Andrew
> _______________________________________________
> Clfs-dev mailing list
> Clfs-dev at lists.cross-lfs.org
> http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
>
>
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.

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.

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.




____________________________________________________________
Do THIS before eating carbs (every time)
1 EASY tip to increase fat-burning, lower blood sugar & decrease fat storage
http://thirdpartyoffers.netzero.net/TGL3341/5252a62362ab826205a7ast04duc