Hops Error, Line 21, alcoholi.c from_blfs.10.defermentmullkegmalt at
Thu Jan 14 11:09:03 PST 2010

<from_blfs.10.defermentmullkegmalt at>:
>> What attracted me to eglibc was the fact that
>> it's less monolithic than glibc while still aiming at compatibility
>> with glibc. I run off an 8-gig USB stick, bla bla bla

>  My understanding is that eglibc is just glibc "in a more appropriate
> form for distros to use", typically with "sensible" fixes applied.  On
> x86, and probably x86_64, that seems unlikely to make much, if any,
> difference.

That's not really what my understanding of it is. The press is that
it's just a fork of glibc where patches are more readily applied, and
behind the e-mailing lists and behind-the-curtain drama that's been
exposed to the internet there is actually a very large kernel of truth
to that.

Nonetheless, Eglibc states that they have the same aim as uGlibc;
supporting smaller systems. Where they differ, is that uGlibc will
work on practically anything, but you have to rebuild your programs,
and Eglibc claims that (many) programs built with glibc will work with
eglibc, but works on fewer embedded systems.

I'm about to quote from their website, but I am definitely not trying
to sell it; the majority of people out there should stick with good
ol' glibc and have all their programs continuing to work properly,
especially given the (un)likelyhood of Eglibc actually being able to
live up to their stated objectives.

That said, from their website,

"Embedded GLIBC (EGLIBC) is a variant of the GNU C Library (GLIBC)
that is designed to work well on embedded systems."

>  I don't understand your "less monolithic than glibc" comment - the
> upstream is the same, but eglibc *should* be easier for a distro to
> use (if I've understood articles at e.g. lwn).

I meant "monolithic" the same way it's used to describe the kernel; a
"main" system with components and/or modules attached to it, as
opposed to being a collection of tiny "main" systems. I said "more",
because while EGlibc hasn't yet been completely cut up into components
(and is thus still monolithic as I'm using the term), it is much more
so than Glibc.

EGlibc has been divided into sections, and you only need to install
the ones you need. That means you can compile your C library
completely without, for instance, any localization support whatsoever.
Same goes for network support, character sets, if you're bored this is
a good read

That's basically EGlibc's main selling point, being able to leave out
stuff you don't want to save disk space and make your C library
compile faster.

>  But surely, there will not be a valid eglibc ticket for _B_lfs :
> if you rebuiild libc in an LFS-family system, you should rebuild
> the whole system.  ( Yes, I know that in the old days of glibc-2.3.x
> some people managed to upgrade across various values of x).
> ?en
> --
> After tragedy, and farce, "OMG poneys!"

That was the meat and potatoes of my question. And I mostly of agree,
that mostly being a completely in the short term.

Playing the what-if game, though, if one day eglibc actually managed a
proven high degree of binary compatibility, would there be
instructions here? In my opinion it is a possibility, with a few
popular distros full of complaining customers and other motivators
switching over.

For that matter, could there be an eCLFS (or "t" for "tiny", or "s"
for "small" or any replacement for "e")?

More information about the blfs-support mailing list