[Clfs-dev] Embedded: Is e2fsprogs really needed in core embedded book?

[Joe Ciccone]

On Sat, 2011-04-09 at 13:22 +0100, Hector Oron wrote: 
> 2011/4/9 Andrew Bradford <bradfa at gmail.com>:
> 
> > I think if people are successful getting stuff to build and run
> > properly on an embedded build, it'd be nice to know.  I'm not sure of
> > the best format, (C)BLFS wiki versus book versus some other medium.
> 
> I'd like to test it for ARM, but I always have trouble to find out
> which it latest and greatest (to test).

I'll be honest, I would rather see a book style system instead of a
wiki. Even for the beyond parts. Maybe wrap a web interface around it
where someone can commit a change. The reason I would rather see this is
a problem we've had in the past with releases of clfs. We can't really
take a snapshot of cblfs to store with clfs. So if you're building the
woefully outdated clfs 1.1.0 the currently cblfs may have some issues
building on top of it as it is expecting some changes in clfs-dev.

For now I say just keep the beyond stuff for embedded in the book itself
just in its own section/chapter system. That way in the future it would
be easy to move out into its own book if we ever want to separate it.

In the coming weeks I'm going to continue the work I started on the
stylesheets to simplify the XML. That should make maintaining something
like that MUCH easier.

> 
> > Which then has to beg the question, would moving embedded to EGLIBC be
> > something to consider?  My impression is the 'E' stands for embedded,
> > but I'm not sure if it's as small as uClibc (I'm assuming it's not).
I'd say no, embedded should stay uClibc. Reasoning below. 
> 
> EGLIBC is GNU Libc (Glibc) with some patches on top so it allows
> better integration with embedded systems. For example, it fixes
> install headers target when building cross compilers, it has support
> for multicore ARM chips, supports building with -Os, etc... it can be
> built to be fully compatible with Glibc, but it can also be built
> disabling some of its fat (iconv stuff, etc..) making it _not
> compatible_ with Glibc. EGLIBC is just an easier to work with C
> library when comparing to Glibc. uClibc vs EGLIBC, it probably needs
> testing and benchmarking, but rumor has it that uClibc performace and
> small(ish) size cannot be beaten but a shrink down EGLIBC, but for me
> it is just a rumour.

You hit this pretty much spot on. However the sysroot book was created
before embedded, it's purpose is to have the full gnu userspace where
the embedded book is super minimal. As small as possible. A user could
easily adapt a build using a mixture of the 2 books that builds eglibc
but instead of the gnu tools uses the instructions for busybox in the
embedded book.

-- 
Joe Ciccone