Saturday, October 19, 2013

Your daily nightmare with ABI_X86

Let's take a break here from the previous post. I don't know if you've read about it, but Portage (hence, Gentoo) is on its way to becoming a true multilib distro, the Gentoo way. This means that in the near future you won't need precompiled 32 bits libraries anymore (thus, effectively removing emul-linux-x86-* packages). This is a good thing...

... is it?

No, seriously, this is a good thing. Gentoo's philosophy of compiling and adjusting packages to your needs clashes with what we've had over the years in the emul-linux-x86 packages (not being able to change anything since they're precompiled binaries, having to wait for a new snapshot if something isn't working properly, etc.); so we're finally bringing the Gentoo philosophy to the multilib part. And this will apply not only to 32bits binaries from the x86 architecture. I've already seen hints of other ABIs for other archs.

This will be implemented with an expand USE: ABI_X86. All you have to do is define this in your make.conf:

ABI_X86="64 32"

Supposing you'll be wanting 32bits copies of any library that supports them so as to properly run e.g. wine. Another way is specifying individual USE for packages:

category/package abi_x86_32 abi_x64_64

However, the road is long and there are many perils. First of all, this is all in ~arch, so if you have a stable system, you can bother to read this when the ABI changes are pushed to stable, hopefully with more documentation. Second of all, if you have a completely unmasked system for ~, you won't notice any problems likely. The thing is, if you have a mixed system (stable but a few things unmasked). This is where all hell breaks loose.

I've already fought twice with this on my PC and one on my laptop, both mixed stable and ~ amd64 systems. Whenever I have one of these wrestling sessions with any of my Gentoo systems, I tend to work fast and loose, trying many things at the same time whenever possible. That is why I don't have a fixed walkthrough that can get you to this, but nevertheless my memory serves me right on some points which I'll write below:

  • You will get many slot blocks the first time around (and probably most of the following times until you've fixed this). This is normal. Don't panic.
  • Consider removing libreoffice, wine and your currently installed emul-linux libraries. You can install them again later.
  • Unmask abi_x86_32 by putting the following into /etc/portage/profile/use.mask (seriously, I'm not joking you in this. I've spent three days fighting with my laptop until this solved everything. The creepy symptom if you don't do this is that most packages will build fine with the 32 ABI, but some Xorg libraries will refuse to merge, and will show 32 as hard negated in ABI_X86 ("(-32)"):
  • If this gets paired with a big world update (as is almost always the case with me and my systems), consider dividing the upgrade by sections and doing those sections first before trying to update world. As an example, on my laptop I first tried to upgrade kde-meta to the newest version and solved first the blockers for that package, before tackling world. This removes around ~300 packages from the world update afterwards.
  • Whenever you have a slot conflict, this is due to the ABI change. Most of them can be fixed by individually upgrading the offending package to the newest version (keep in mind that most likely the newest version will be the one supporting the ABI changes. And also keep in mind that you might need to unmask said newest version of the package).
That's all I can remember for now. I seriously hope more documentation to come before the ABI move to stable. And I seriously hope noone has to go through this hell again.