It appears that like me, many users have struggled in recent weeks with upgrading following the move to abi_32 compilation. Could I please press one of our hard working developers to give us a quick overview of the changes and how to manage them? As a starter, let me explain my findings and understanding so far, and feel free to correct me if I have misunderstood.

The suite of files emul_linux_x86* will be obsolete once the whole of portage is changed over to the new structure

A number of ebuilds have not been changed to use the new approach yet, or at least not in stable versions

Neither a fully stable system , nor a fully unstable system has any problems. The challenge comes for systems like mine with a mixture of stable and unstable packages.

In order to use the new approach, you need to unmask the abi_x86_32 flag in /etc/portage/profile/use.mask:

Code:

-abi_x86_32

In addition, you need to add the flag abi_x86_32 for packages for which you want to compile the abi_32. Alternatively you can add the flag globally in /etc/portage/make.conf:

Code:

ABI_X86="32 64"

In actual fact, the 64 is not necessary here, as I have an AMD64 system which means abi_x86_64 is enabled by default.

In order to eliminate the mixed condition, you need to find dependencies on emul_linux* and see if any of the ebuilds have been modified to use the new flags. You can the upgrade those packages accordingly. In some cases, the existence of the multilib flag will optionally add a dependency. Unsetting the multilib flag will remove this.

I have to declare a lack of understanding of the technical background to abi_32 etc., so I welcome additions and corrections to this list. I would be happy to summarise and add a page to the wiki is that helps.

For my system, I am starting to question exactly why I have a multilib system, and whether I should move to a 64bit only system! (would it be quicker.....?)

It appears that like me, many users have struggled in recent weeks with upgrading following the move to abi_32 compilation.

Indeed.

Quote:

I have to declare a lack of understanding of the technical background to abi_32 etc., so I welcome additions and corrections to this list. I would be happy to summarise and add a page to the wiki is that helps.

Well, let me just say "thanks" then, as you've done an excellent job so far, and this does need to be documented with review.

Quote:

For my system, I am starting to question exactly why I have a multilib system, and whether I should move to a 64bit only system!

I'd hang in there for a bit: this is a transitional phase, bumpy as it is.

If it goes on for more than another month or so, I'll be concerned, since it has been going on for a while now.

I'm already running wine without emul-linux-* packages with a few additional ebuilds from FireBurn overlay, but it doesn't work with several dependencies and I had to create one intermediate -32bit ebuild with a tiny subset of yet-to-be-converted libs. I mostly did that to save a lot of unnecessary build time while packages are still depending on emul-linux-* that are becoming merely meta-ebuilds pulling in all the deps that were provided as binaries before.

The transition will certainly go on for a while as there are plenty dependencies involved. Affected people are ~arch users and those who are running mixed arch/~arch packages with probably long forgotten entries inside their package.keywords and package.unmask dirs, so that will be an opportunity to look into those. Nothing that a bit of (un)masking couldn't solve._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

I am not using wine here. If I need to access windows, I have an XP virtualbox installation set up. I am not sure which package exactly led me down the path of having to deal with this issue. I have a mixed system of arch/~arch, but when utilising an unstable package I normally mark the current unstable version as ~amd64, not any version of the package. This has recently become more difficult, as it now seems the approach is to remove the ebuild for an unstable version if a newer unstable version is added, and the original unstable package is not going to be made stable. This leads to emerge wanting to downgrade packages, which then causes more dependency issues especially around abi_32!

Hopefully at some point one of the developers will give us some more information. I am not sure about migration from no-multilib setup - I was going down the no-multilib path when setting my system up, but fell at the first hurdle (grub-legacy)

I am afraid migration from no-multilib is almost impossible (or at least as hard as migration from 32 bit to 64 bit; you will have to build cross-compilers and what else...). Probably you will have to reinstall with a multilib profile if you want multilib.