A “new” C library

Debian announced they are going to move away from the GNU C library toward eglibc, a derivative designed to work on embedded systems; not even a few hours after I shared it on Google Reader myself, I was contacted regarding a Gentoo bug for it . Since I don’t like repeating myself too much, I’m just going to write here what I think.

First of all, the idea is interesting, especially for the embedded developer in me (which is still waiting for the time to go buy the pins to solder on a serial port on my WRT54GL ), but also for the “alternative” developer in me. I have worked on Gentoo/FreeBSD and I always hoped to find a way to handle an uclibc chroot to test my own stuff. Testing eglibc is going to be interesting too (if only I had time to finish analysing the tinderbox logs, that is).

What I do find quite unfunny, and a bit discomforting, is that half the “features” that Aurélien Jarno lists are “we don’t need to deal with Drepper”. Now, I agree that Ulrich is not the best person to deal with (although I’d sooner deal with him than with Ciaran, but that’s another problem *edit: since it wasn’t really a good example here, I wish to explain it; it is public knowledge that me and Ciaran don’t get along too well, I don’t like his solutions and his methods; on the other hand, while I dislike Ulrich’s methods too, I have less problems with his solution, and I never had a personal quarrel with him, there goes my “I’d sooner deal with him” comment* ), and I also agree that his ideas of “good” sometimes are difficult to share (especially when it comes to implementation of versioning for ELF symbols which gave me such an headache to replicate in Ruby-Elf). On the other hand, I wonder how much of that choice is warranted.

What most people seem to compare this to is the move from XFree to Xorg, or to the fork of cdrecord into cdrkit. I disagree with comparing this cases with those two. Both those were due to license issues, which, for people caring about the freedom of their software, are one of the most important issues (unless, of course, you just don’t care and go on forth with piracy — which is what actually brought me to a bit of a nervous point with ALTlinux in the past). While not having assholes around is probably as important (and I’d point to this book which I remember Donnie describing before; unfortunately I haven’t had the pleasure to read it yet), I still don’t see this like the brightest move Debian could have done.

More to the point, the cdrkit fork doesn’t look like one of the shiniest things in Free Software; while cdrecord is no longer the massively single point of failure for CD/DVD burning in Linux, one has to note that this is also due to other projects, like libburn, having had an injection of development and race toward support, once the idea that cdrecord wasn’t good to keep started flowing around. And the XFree to Xorg move was extremely helped (and made successful) by the fact that the developers for XFree itself moved out of the project toward Xorg.

I’m not criticising Debian’s move, I’m actually thrilled to see the results; I’m not criticising eglibc, I’m very interested in the project. I’m just trying to throw a water bucket over the people who seem to be on fire about eglibc now. I don’t see this like a huge paradigm change for now. Once eglibc has huge advantages (which for now I don’t see), we can probably get passionate about moving. Right now I don’t see this huge change, there are neat ideas and certainly it’s a good thing not to have assholes blocking the project, but is that enough?

Now, more to the Gentoo side of the thing; I’m not part of the toolchain team, so I don’t know if they have any particular, special plan about this. I would expect them not to for now at least; adding support for a new C library is not impossible, but it’s not easy either. I might be worrying for nothing, but I don’t trust the “100% compatibility” that Debian seems to ensure about EGLIBC versus GLIBC, even if it’s just bugfixes over a given GLIBC version (which would bring me to my hate of forking projects); I wrote some pieces about the difficulty of ABI compatibility and while I did also show how to keep backward compatibility, I said nothing about forward compatibility.

Also, I don’t trust Debian’s assurances that it works with all the software; open-source or not. The reason is not only to be found in Debian not being that reliable but also in the fact that we’re not Debian: we have differnet patchsets, Debian tends not to send stuff upstream, and so on. We also leave the user with full access to tinker with features, which would mean being able to disable certain stuff from eglibc (I’d welcome that, there are a few things that I’d like to disable on my server for instance); in turn this means that either some USE flag configurations will get unsupported (or unavailable), or we’re going to need special dependencies to ensure that certain pieces of the C library are enabled for eglibc. Bottom line: we’re going to need a long test period either way (to be noted that we have big problems even between minor bumps of the same C library – think glibc 2.8 or 2.9, or FreeBSD 6.3 – which means that we’re going to need lots of testing to move to a new C library altogether).

Adding to this, is the fact that adding a new C library will mean new profiles (new profiles to test too), and new stages. Which means more work for everybody. Doesn’t mean that it’s not going to happen, just that you can’t expect that to happen tomorrow.

11 thoughts on “A “new” C library

  1. Stephen (because I know it’s you, as usual), that I have problems working with Ciaran is nothing new. That I don’t have any (personal) issue with Ulrich is also known. I just stated the obvious.But you’re right, I’ll amend the post (and leave the comment) since without explanation it might sound uncalled for.

    Like

  2. Since when does Debian not forward patches?? Personally I commit upstream where possible and backport to Debian. Where I don’t have access I’ll always file a patch in the bug/patch tracker.

    Like

  3. Had quite a bit of patches to be found only on Debian’s packages, never forwarded upstream.And your comments would sound lots less trolly if you were to tell who you are.

    Like

  4. I think the dealbreaker for Debian was Ulrich Drepper declaring ARM “unsupported.” Considering it’s an increasingly important architecture for them (and for their downstream, like Ubuntu), that’s just unacceptable from a technical perspective, let alone a personalities one. They really had no option but to go elsewhere.

    Like

  5. Norman, I had that reported already but didn’t have time to fix, should be fixed now though.David, well, moving to eglibc for ARM right away would have been just logical, moving to eglibc for everything I’m not really sure.But we’ll have to see, as far as I can see now it really doesn’t diverge that much from a glibc patchset like the one Gentoo is also maintaining. Maybe eglibc an turn out to be a shared patchset among distributions where to maintain things that we all more or less want and Ulrich won’t provide, but that really sounds a lot like EGCS…

    Like

  6. I had been waiting to see opinions from Gentoo devs on this. It’s about what I expected and wished, myself, basically, don’t go off half cocked, it’s an interesting development, but will take quite some work and time to support on Gentoo, if indeed we ultimately go there at all (tho really, I’d say chances are /someone/ will, given the flexibility that is Gentoo and the various projects we already have).On the Ciaran thing, debatably inappropriate before (tho it’s your blog and censorship isn’t good either), but appropriate explanation, and a nice way of putting it, separating the methods and solutions like that. It’s OK to “agree to disagree.”

    Like

  7. Presumably they wanted Debian to remain as unitary as possible. I presume this move had considerable thought put into it. The trouble with glibc on ARM dates back to 2007, after all.It’s interesting to note that just about *everyone* in fact maintains their own patch set against glibc. Even Red Hat and Fedora don’t ship a vanilla glibc. So a place for everyone to put their patch sets together is a very good idea.

    Like

  8. what scary me is the *alloc implementation of the eglibc; Debian will follows the actual efforts of the glibc Team tring to implement a better multi-treaded memory allocator (which improve scalability on modern multi-core archs)? or eglibc will stick with the old single-threaded memory allocator?I hope to not lose features just for the Debian pride. Sorry but actually I don’t buy the eglibc view, neither in the long term.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s