New GLIBC, new trouble?

After a false start hitting a stupid invalid bug I have finally switched the tinderboxes around for the next round: instead of testing gold, I’ll be testing glibc-2.14 for the next two weeks or so.

I already said I can’t easily tell which bugs are fixed that could impact, at build- and run-time, Gentoo users, but on the other hand, I know that we might get some trouble related to the RPC interface. A bit of history here might be worth it.

GLIBC has integrated for a long time some SunRPC code that had a number of defect: it couldn’t cross-compile cleanly, it was under a non-totally-Free license from Sun Microsystems (which is why a number of distribution that insisted on being 100% FSF-Free would be laughed at quite often), and it didn’t support IPv6.

Now, to overcome a number of these issues, a new library was created called libtirpc, which implements “transport-independent” RPC; it solved both the cross-compiling and the IPv6 problem, and last year thanks to RedHat and Oracle, the licensing issue was also made moot.

This library is already required by the current versions of NFS utilities in Gentoo, which means that you most likely are already relying on that. I’ve also made some fixes to it before. I’m positive that at least the RPC trouble will be easy to identify and to deal with on the medium term.

While I was intending to start the tinderbox on the new glibc version on Sunday (posting this on Monday), I had a couple of delays added over it. First of all, if you have the GCC_SPECS environment variable set incorrectly in the environment, gcc -v --help will refuse to report ld’s known options, which in turn means that the ./configure check used to identify whether some features are available is going to fail.

Then there is another issue: glibc’s build will abort mid-run, when building with GCC 4.6.0 and a Gentoo patchset earlier than 1.2. Unfortunately this is not so obvious, given that, by rule, patchsets for GCC that does not solve possible runtime issues are not going to cause a revbump, and by definition masked compiler versions do not get revbumps when the patches are changed. So if you wish to use gcc 4.6 and glibc 2.14, make sure you rebuild the former as first step.

After finally getting glibc merged in the tinderbox, and after cleaning out the fifteen thousands packages that got merged on it – okay some are virtuals or no-build, but that’s beside the point – I started the rebuild of just about everything.

One of the first packages showing a problem, interestingly enough, wasn’t related to RPC .Ruby 1.8 fails to build for a generated source file that looks corrupted. While I haven’t gone into the details debugging the issue, Alex’s read of the glibc ChangeLog suggests that we’re hitting an Adobe-grade bug, with operations applied to overlapping memory areas when they shouldn’t. Unfortunately short of using valgrind during generation I can’t think of another approach to find this out.

Task for the night is also to test whether the base version issue I written about last week, and tomorrow I’ll be back talking about gold.