Slashdot Mirror
Debian Switching From Glibc To Eglibc
ceswiedler writes "Aurelien Jarno has just uploaded a fork of glibc called eglibc, which is targeted at embedded systems and is source- and binary-compatible with glibc. It has a few nice improvements over glibc, but the primary motivation seems to be that it's a 'more friendly upstream project' than glibc. Glibc's maintainer, Ulrich Drepper, has had a contentious relationship with Debian's project leadership; in 2007 the Debian Project Leader sent an email criticizing Drepper for refusing to fix a bug on glibc on the ARM architecture because in Drepper's words it was 'for the sole benefit of this embedded crap.'"
uClibc is not binary compatible with glibc, so you can't compile on one and run on the other. Heck, uClibc is generally not even binary compatible across versions -- you have to recompile the whole system every time you update uClibc.
That's not to say uClibc isn't useful, but it doesn't have the same goals (or features) as glibc or eglibc.
Because uClibc has(had) inferior threading and performance. And it is(was) missing the GNU extensions that many popular FOSS projects depend on.
There is also newlib and dietlibc. In many ways I find newlib to be better than uClibc, although I still tend to use uClibc for projects because it's good enough and we already use it.
“Common sense is not so common.” — Voltaire
Devices like MP3 players, set top boxes, and mobile phones account for far more GLIBC deployments than desktops and servers.
Not only that, but Drepper was taking with where the change was being made. He was suggesting that the alternative implementation be in an architecture-specific file rather than changing the generic implementation.
In other words, in this particular case, the idea was that the original patch would incur a performance hit to x86 and other mainstream architectures in compensating for ARM's differing alignment. Consequently Drepper wanted the change to be done in a platform-specific file outside of his purview.
" Any change will negatively impact well
designed architectures for the sole benefit of this embedded crap."
^ Actual Quote.
Not even an old program written from Loki Software Entertainment would run on a modern Linux Mint (2.6 kernel) for example unless in a chroot'd sandbox. Truly sadistic, that I even remember this happening even on the same kernel branch. Bruce Perens would address this better than I, but my time is worth more elseware.
You can do it by installing the old libraries and using LD_LIBRARY_PATH and LD_PRELOAD. See the Gentoo Wiki archives for information and a tarball of the necessary libraries.
Not the most elegant solution, but it's easier than dealing with a chroot.
Don't leave your mind so open that your brain falls out. Don't close it so much that you cut off the blood.
And this is from a single bug report alone.
You are aware I hope that the last comment (and one earlier) is from a fake Drepper? (check the mail addy)? :)
He refused nscd patches to fix issues in glibc that had numerous gross errors like:
1) assumed all replies arrived in one packet
2) database storage mishandling
3) zero-length returns from syscalls due to unrelated signals
And then last year he "found" many of these bugs and finally fixed them the same way, after rejecting the same patches 3 years earlier. Ulrich Drepper is the reason nscd sucked so badly for so many years in Linux, as he's the reason for so much other suckage, and the reason most distributions end up with a heavily forked glibc anyway. This is just sharing those forks - the forks happened many years ago in every distribution that works. Even Redhat has a glibc that's heavily forked from the mainline, and they pay him.
Drepper does come across as an asshole totally antagonistic to ARM and embedded development. But after a little googling, I'm convinced his thinking is a little more complicated than that. Basically, he seems to think that glibc is poorly suited to embedded applications, and wishes that ARM developers would develop their own specialized libcs.. He's also concerned that in GCC development, the needs of some platforms that happen to have powerful backers (such as AIX) get more priority than their mindshare deserves.
He's got some good points. He does express them in a way that's unnecessarily offensive and combative. But that doesn't make him an asshole. That makes him a typical geek!
For even more context, look at the patch. The "negative impact" is a couple extra microseconds of cpu time to memset 20 bytes instead of 3. I guess 32-bit x86 ought to be enough for anyone.
Do you even lift?
These aren't the 'roids you're looking for.
It's horribly inefficient BSD crap. Get your Drepper quotes right!
The Yasashii Syndicate ||
yes, nanoseconds. If that.
Just for kicks, I compared memsetting 20 bytes (aligned) vs 3 bytes (unaligned) with llvm-gcc (which can output code in a dozen assembly languages).
For mips, sparc, and ppc32, a 3-byte unaligned memset must be done 1 byte at a time, so the 20 byte memset is only 2 instructions more (5 32-bit stores).
For 64-bit alpha and ppc64, the 20-byte memset only uses 3 instructions (2 64-bit stores + a 32-bit store).
x86 (and arm, for that matter) can do a 3-byte memset as a 8-byte set and a 16-byte set.
Do you even lift?
These aren't the 'roids you're looking for.
The ABI is compatible with glibc, this doesn't preclude them from including new functions like strlcpy and strlcat - which again looks like something that Ulrich Drepper doesn't think is a good idea. In fact, the man went so far as to reject the patch, stating that:
Fork couldn't have come soon enough!
XML is like violence. If it doesn't solve the problem, use more.
Indeed - and not just ordinary, non-involved people. In one bug alone, he managed to upset Gentoo's Mike Frysinger, he told Petr Baudis of SuSE that "I never saw your name on my paycheck. Since if that's not the case you cannot order me around., and gave the MirOS developer Thorsten Glaser cause to comment on Drepper's standards.
Nice going!
XML is like violence. If it doesn't solve the problem, use more.