Gold rush — The troubles of using gold for testing

In my previous post I have listed a few good things that come with the stricter behaviour implemented by the gold linker, and why I’d like to use this for testing. You also know that the current released versions are definitely unreliable and unusable for testing (or any other) purposes.

Well, version 2.20 (which is the latest “stable” release of binutils) is quite ancient by now, and indeed, 2.21 is coming out soon, so I actually went on to test the status of gold in that version: it works, sort-of. Indeed, with the current working version of gold, that, among other things, can – and I’d venture to say should – be built separately, you can build a good deal of packages. But by no mean all.

It’s not just a matter of what fails because of the underlinking prevention of which, I hope, I have conveyed the positive effects and the reasons why we should enforce it more strongly, but rather of the fact that we know for a fact of at least one bug where gold fails to execute properly when correctly using the documented syntax.

The above bug is a split-up of the issues that fuse itself has when built with gold: from one side there was a bug in fuse (the same symbol listed in two version names within the linker script), and that was fixed upstream; on the other hand, the following syntax, described by the binutils manual itself:

__asm__(".symver original_foo,foo@");

This is supposed to declare the symbol foo in the base version; it is not replaceable with a linker script either since there is no way to define the base version in there if any other version is defined. On the other hand, gold has gone up to now without implementing the feature. Willingly. And it’s actually not an entirely bad reason why it has been doing so: the reference implementation for this stuff (GLIBC) Is broken in this regard.

Indeed, it seems like, instead of actually using the base version first when a symbol without version is provided, GLIBC prefers another symbol, not even the default symbol — most likely, it depends on the order of the symbols in the ELF file. The result is, at any rate, pretty bad, because the binary compatibility between version 2.0 and all the following ones, for what concerns FUSE, is not really present: binary compatibility is ensured only since they started providing versioned symbols, so from version 2.2 onward.

Now, how to move forward from here depends vastly on whether version 2.21 will have the bug fixed or not; if not, then I think the only way out to solve this would be to install a separate gold package, installing a binutils-config configuration file to select it as default linker — this one is a nice trick, whose idea I lifted directly from the chromiumos-overlay binutils ebuild.

Indeed, using a separate ebuild would also help if we were to find some other problem with gold, failing to build or producing bad results for a package; I’m pretty sure that if my tinderbox would run with gold, it would be the big deployment it would need to be called “usable”. Yes I know there are other projects using it, but given there are still relatively big issues like the one I pictured above, I expect that it wasn’t really polished around enough yet. This would probably take care of it.