Fixing libtool

You might have noticed that Gentoo has been lacking libtool 2.2 support for quite a while; this has been quite a problem because libtool 2.2 among other things shorten the time needed for the execution of ./configure as it doesn’t unconditionally check for C++ and Fortran, and at the same time, quite a bit of packages have been using the new libtool now.

While a lot of packages using libtools were easily worked around by removing the libtool macro files and regenerating the autotools using whatever libtool the system cam with (so that they could be marked stable even with libtool 1.5), this only worked as long as upstream didn’t decide to update the calls to libtool as they should have been doing. And more importantly, the LTDL-based packages, like PulseAudio, almost always failed to support both libtool 1.5 and 2.2, so lots moved to simply supporting 2.2. PulseAudio, well, being one of them.

So to have new versions of PulseAudio stable, we needed the new libtool stable. Piece of cake, no? Well, no, beside the packages failing with libtool-2.2 there were a few test failures reported in the stable request bug, that went lingering for a while; as much as I like autotools, I’m not the maintainer in Gentoo for any of them, since I’m not in the base system team. But since people started complaining (somewhat rightfully) about PulseAudio 0.9.9 being ancient, and asked for a stable of a newer version, on Sunday I went to look at the test failures.

The results, have been much simpler than I expected; especially counting in that nobody else looked at them in the time before, with the exception of a few users playing with the vanilla USE flag:

• one test was caused by the elibtoolize patches — we don’t want those applied to libtool itself!
• one test failed when the system lacked German locale (it tests localised messages, and uses the German locale to do that); this was already worked around upstream by skipping it whenever the German locale is unavailable, backported to the Gentoo ebuild;
• one more test fails because… the other failed; the test that ensures that libtool works even when the maximum size of parameters is very short simply re-executes the testsuite recursively; this gives the test two error-out cases: when libtool is broken with short max parameters, and when something else is broken, not nice!
• finally, there was another test failure, that I couldn’t reproduce, but that seemed tied to --as-needed; after some headbanging around, I noticed the way the test failed (indirect link), and indeed, this seems to be a problem with the older, stricter --as-needed behaviour; I already wrote about the softer --as-needed back in February, if you don’t know what I’m talking about;

As it turns out, getting the testsuite proper so that it can be trusted wasn’t especially cumbersome or painful; it only took half an afternoon of mine to fix most of the evident problems, and the last one is not a stable showstopper (as much as I like --as-needed, a failure in a testsuite because of it is not a stable showstopper, although I’d like to get the test fixed).

What can be noticed here is that once again we’re lacking people who actually go check the problems and fix them up. We need more people who can look at this kind of stuff, we need more users to insightfully note the bugs; if it wasn’t for Pacho Ramos and Dustin Polke who, in the bug looked up possible points of failures (icecream and the vanilla USE flag — the latter made a bell ring on my head about elibtoolize), then libtool 2.2 would probably be still far, far away for Gentoo stable. Thanks guys!