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
[email protected]
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
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
