A couple of days ago I noted the move to glibc 2.14 of my tinderbox with the hope to quickly find and fix the packages that depend on the now-removed RPC interface. I didn’t expect this kind of apocalypse, but I’m almost wanting to cry, thinking about the mess this version seems to create.
First of all, it doesn’t seem like it’s just Ruby being hit by memory corruption issues, which makes it likely that the new memcpy() interface noted in the ChangeLog is to blame. I haven’t had time to debug this yet though.
A new scary situation arose as well: wget exits with a segmentation fault when trying to resolve any hostname that is not in /etc/hosts, which in the case of the tinderbox means anything that is not localhost or Yamato (as that’s where the Squid proxy is added that caches requests for the fetched Gentoo data). I’m not sure of the cause yet, as the fault happens not within the executable’s code but directly into libresolv, which would point at a bug in glibc itself.
For what concern RPC, I’m surprised that there are so many packages depending on it, and of the widest variety: multimedia, scientific, network analysis tools, and so on. Now, I was optimist in my previous post, expecting that for most, if not all, of the packages using RPC would be fixed by relying on libtirpc. Ooh boy, how wrong I was.
See the issue is this: libtirpc itself does not build on glibc-2.14, as it relies on one of the NIS/YP headers that has also been removed. Even worse, the latest version (0.2.2) of libtirpc, which I hoped would solve the issue, does not work on any system at all, since a change by our very own Mike (vapier), which was merged upstream just before 0.2.2 release, causes the build to produce a library that lacks a couple of symbols — the source file where they are defined was not added, but even when you add it, you get a couple more symbols being missing. And this release has been out for over a month without any sign of a 0.2.3 coming (upstream repository is still broken, at the time of writing).
Are you freaking kidding me?
Oh and for those who wonder, the issue with base versioning that, as I’ve told, is holding up implementing base version support in gold, is still not fixed. This means that packages such as fuse, included, who wanted to keep binary compatibility with their original unversioned symbols are still not getting any compatibility, even with this version. In my personal opinion it would be a good time to drop the code for that in fuse, but upstream prefers waiting for the new 3.0 version, which is going to get tricky.
With all this considered, it really looks like a very badly broken release, and one that makes me wonder if it wasn’t too inconsiderate to reject the idea of moving to the eglibc patchset/fork like Debian and Ubuntu seems to have done.
Don’t forget: http://sourceware.org/bugzi…This bug was introduced because Ulrich took some(bug-free) patches from Andreas Schwab and messedwith them.When you look at the git glibc history you’ll seethat Ulrich merged most changes 1-2 days beforethe 2.14 release. So nobody had a chance to review them.I think it’s time for Ulrich to step aside as glibcmaintainer.
BTW you can find the the libresolv bug here: http://sourceware.org/bugzi…
I hope someone will stops Vapier from commiting glibc-2.14 to tree, because it will be even bigger disaster than the one with prelink and 2.13.
Switching to eglibc would definitely be lovely.As I remember, vapier said he’d consider eglibc if it weren’t for the upstream, for some braindead reason, using SVN.It’s also interesting to note that Drepper, after 14 years of working at Red Hat, as of 6 months ago, he’s been employed by Goldman Sachs…
>It’s also interesting to note that Drepper, after 14 years of working at Red Hat, as of 6 months ago, he’s been employed by Goldman Sachs…Haha, that’s fitting. Just double checked and it’s true he is now:VP, Technology Division at Goldman Sachs
That is why people have a problem with removing features, because while there usually is a “replacement”, that replacement usually is barely (or as here, not at all) tested because nobody considers it important (if anyone thought it important they’d keep compatibility a bit longer, at least until a major bump – admittedly that rule doesn’t apply well to a libc).Though the “replacement” depending on the thing it is supposed to replace seems like a fail of unusual proportions.
Yes, please let us use eglibc in Gentoo.