<[email protected]>: >> 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 www.eglibc.org, "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 http://www.eglibc.org/cgi-bin/viewcvs.cgi/trunk/libc/option-groups.def?view=markup 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")? -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
