So it’s said that it’s not possible. Not supported perhaps, but definitely possible. Writing this here for reference, it’s also not supported in any way seeing that I’m not even close to what can even remotely be considered an expert in the field. I just figured someone else will run into the same situation, and might find this useful as a base to work from.
Well, the reason why “it’s not possible” is because your toolchain is broken. Not really, but there are requirements and either you need to go building a cross-toolchain using crossdev, or you need to obtain the required toolchain in some other way. Frankly, the thought of going through crossdev is an interesting one, but there exists a simpler strategy. Compiling the toolchain on the box itself fails. Note, compiling, not portage failures. This means that we are likely able to install binary packages, and this is the crucial clue.
In the case where a multilib machine is available, just create binary packages there, otherwise, follow instructions below.
Well, the normal strategy is a re-install. We’re going to cheat, we’re going to somewhat install a new system, then build binary packages and just use those. So download a stage3 AMD64 stage tarball. I then did this (for obvious reasons as root):
mkdir /home/multilib tar xvpf /path/to/stage3-amd64-??.tar.bz2 -C /home/multilib mkdir /home/multilib/usr/portage for i in usr/portage dev sys proc; do # Changed to use --rbind from --bind - as per the manpage this # mounts sub-mounts too, incl. /dev/shm which has recently become a problem. mount --rbind /$i /home/multilib/$i done cp /etc/resolv.conf /home/multilib/etc/ cp /etc/make.conf /home/multilib/etc/ mkdir /home/multilib/etc/portage cp /etc/portage/package.* /home/multilib/etc/portage/ chroot /home/multilib
Probably not required, but I want portage inside of and outside of my root to be the same to reduce the risk of things going wrong:
emerge -uav portage
At this point, also double check that you’ve got a sane profile selected, I just use the base one:
tiny ~ # eselect profile list Available profile symlink targets:  default/linux/amd64/10.0 *  default/linux/amd64/10.0/desktop  default/linux/amd64/10.0/desktop/gnome  default/linux/amd64/10.0/desktop/kde  default/linux/amd64/10.0/developer  default/linux/amd64/10.0/no-multilib  default/linux/amd64/10.0/server  hardened/linux/amd64/10.0  hardened/linux/amd64/10.0/no-multilib  selinux/2007.0/amd64  selinux/2007.0/amd64/hardened  selinux/v2refpolicy/amd64  selinux/v2refpolicy/amd64/desktop  selinux/v2refpolicy/amd64/developer  selinux/v2refpolicy/amd64/hardened  selinux/v2refpolicy/amd64/server tiny ~ #
Updating the toolchain
The question here really is what’s all part of the toolchain. This is a valid question, and frankly I’m not an expert. The easy way is to just make binary packages of the entire default system, you probably want to recompile most of your libraries etc anyway, so we can just as well do this inside the chroot and use the binary packages outside. So by wasting some extra cycles we make this easy:
emerge -euav --buildpkg system
After a while you’ll be prompted to recompile everything in the stage tarball, probably most things will be upgraded anyway (probably). I’m not a fan of wasting CPU cycles for the heck of it, however, I’ve got other things I need to be busy with. So I’ll just burn the CPU in the background and be done with it for now.
Returning to the no-multilib system
Right, now we switch the profile:
eselect profile set default/linux/amd64/10.0
And now we remerge system (remember the binary packages was created in a bind mounted /usr/portage so there is no need to copy things around).
emerge -euavk1 system
Before saying yes, make sure that anything that looks critical says “binary” and not “ebuild”. On my system everything was labeled binary so I just proceeded.
Whether or not world needs to be rebuild or not I do not know. I’m not going to waste that number of cycles at the moment, but if/when time permits and you’d rather be on the “save” side, you’re welcome to remerge world with:
emerge -1euakv world
This will include system, but for system it will use the binary packages if they are still applicable, meaning it won’t waste as much time (especially on things like glibc which can take a while to compile).
I can confirm working by having merged wine after this, and actually starting up winbox.