Risky linkers

I don’t usually advertise much of what I do as a job for a living, and I’d like to keep it this way. It’s usually easy to guess when you look at what my commits are though; so for instance, when you see me committing new versions of net-proxy/squidclamav you can guess I’m working for proxy for the usual customer of mine. When you see me committing a version bump for sys-block/dd_rescue you guess I have a broken harddisk to recover data from, and so on.

Interpreting the stuff I’m committing around the tree for my latest job is probably quite tricky and will likely lead nowhere beside the need to get things cross-compiling correctly but that’s not something new, I have done it before. It might lead you a bit more when you think that I’m currently looking at working on getting packages to play nice with the gold linker. Yes the linker I criticised in many places.

Beside the fact that using the gold linker is required for what I’m working on, I have another interest in trying it out: it has neither the soft --as-needed behaviour, nor it seems to shut up if a symbol can be resolved in an indirect dependency (which is a behaviour shared with the Apple linker). This makes it particularly interesting for testing proper linking.

Now, I know a few people wondered why the gold USE flag was dropped from the tree ebuilds altogether; well it turns out that it’s quite disruptive still; this is what happens on the main tinderbox after rebuilding gold with gold itself:

tinderbox ~ # ld -v
Segmentation fault

Unfortunately I didn’t pay enough attention to this when I first tried it, so the result is that the 64-bit tinderbox is currently out of order and needs to be re-created from scratch. This is twice unfortunate because I didn’t back it up after setting it up, so it’s going to take quite a while before I can resume the 64-bit builds (for the 32-bit builds it’s going to take just a moment as I can simply download a safe binutils binary package).

Now, I’m sure there are working versions of gold – as I’m actually working with one on a separate container – but if I may, I still am a little concerned that, over two years after gold became the news, we still lack a version of it that is sufficiently stable to provide us with a daily-basis usable linker. Not that it says anything; I’m pretty sure that with the exception of developers, integrators, and Gentoo users, there is little interest in having a fast linker, so the fact that it doesn’t get much attention to be implemented in a timely fashion really doesn’t concern me as much. On the other hand, it shows that sometimes, even though rewriting everything from scratch in a different language can gain you a lot in better design, you still lose a lot in either flexibility or knowledge base that is still very important, and would regress if missed.

Anyway the bottom line for this is that I won’t be able to use the stricter gold for testing linking on the tinderbox, just like I cannot use --no-undefined or sneak -Werror-implicit-function-declaration into the compiler’s flags, even though all of those are pretty good devices to identify issues. Sigh!