# HOWTO: Back from an amd64 no-multilib to a multilib system.

## wykladowca

I was recently forced to recompile some 32-bit libs, since my new processor supports the hardware accelerated virtual machines technology, which I would like to use. Reinstalling the system from scratch would be painful, so I came up with a different solution, which I would like to share with you.

What we need for building a multilib system is gcc and glib able to compile 32-bit executables, but to compile those apps in this configuration we need gcc and glib able to compile 32-bit executables. Because of this recursion, a simple changing of the profile and recompiling will not work. However, we can use an another gentoo installation to give the things a little push.

Login as root, and obtain the most recent stage3 tarball (wget it from the favorite mirror). Next type few commands, that will set up an environment to which you will later chroot:

```

mkdir /helper

tar -xapf stage3-amd64-*.tar.bz2 -C /helper

mkdir /helper/usr/portage

mount --bind /usr/portage /helper/usr/portage

mount --bind /dev /helper/dev

mount -t proc none /helper/proc

mkdir /helper/target

mount --bind / /helper/target

```

Before chrooting to the newly untared system, adjust profile of your main system

```

eselect profile list

eselect profile set [number_of_selected_profile]

```

If you use paludis, remember that it stores the profile for repositories in its own configuration files.

Back to chrooting

```

chroot /helper

mount -t devpts devpts /dev/pts

```

And now emerging of gcc and glibc. If you want, at this point you may check the sub-system portage profile or adjust its make.conf (and set makeopts), but skipping those points rather won't be fatal.

If you use stable branch type:

```

emerge --root=/target --root-deps=rdeps gcc glibc

```

And for testing branch, type:

```

ACCPET_KEYWORDS="~amd64" emerge --root=/target --root-deps=rdeps gcc glibc

```

After emerge finished, type "logout" to get out of the chrooted environmet.

Although the described process will not provide you with a complete multilib system, the rest of needed steps (e.g. emerging libraries) can be made from the main system, since the basic tools are available from this point.*

The clean up code is

```

umount /helper/dev/pts /helper/dev /helper/proc /helper/usr/portage /helper/target

rm -R --one-file-system /helper

unlink stage3-amd64-*.tar.bz2

```

Remember, it is always good idea to backup things! (I have been running altered system for few hours now, so I am not 100% sure if I did not brake down anything)

*-in order to compile virtualbox-ose I needed also emul-linux-x86-baselibs and emul-linux-x86-xlibs

----------

## mimosinnet

I have been recently been in a similar situation. I had a no-multilib amd64 and I needed a multilib system. I successfully followed the Howto switch to multilib in the HOWTO_AMD_64 article in the old gentoo wiki. 

Cheers!

----------

## sera

Get glibc and gcc from tinderbox and "emerge -K" them is yet  another possibility to get things going.

----------

## sips

 *sera wrote:*   

> Get glibc and gcc from tinderbox and "emerge -K" them is yet  another possibility to get things going.

 Yep, that seems the easiest way.

I just did it yesterday (also included sandbox from tinderbox) and after some rebuilds, everything working as expected.

----------

## eyoung100

 *sips wrote:*   

>  *sera wrote:*   Get glibc and gcc from tinderbox and "emerge -K" them is yet  another possibility to get things going. Yep, that seems the easiest way.
> 
> I just did it yesterday (also included sandbox from tinderbox) and after some rebuilds, everything working as expected.

 

That was the easiest changeover I've ever had:

```
eselect package-manger set portage
```

 (in case you're a paludis guy) --pbin is not in the same binary format

```
rm -vR /etc/paludis
```

```
emerge -K glibc
```

```
emerge -K gcc
```

```
emerge sandbox
```

```
./portage2paludis.bash
```

 get script

rebuild empty tree, a.)emerge -eav world, or b.)paludis -i --dl-reinstall always --continue-on-failure if independent installed-packages

```
eselect package-manager set paludis
```

----------

## hardly

This was a big help. :-)

----------

## jkroon

Another mechanism, which I used yesterday before someone pointed this out was to use my laptop (which is of similar arch) to build binary packages for the server I had which had a broken gcc (reason unknown).  Firstly use gcc to figure out what -march=native would actually set:

```
gcc -E -v -march=native -</dev/null 2>&1 | grep cc1
```

This will output something like:

```
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1 -E -quiet -v - -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=core2
```

Then use emerge -pv to figure out what exactly will be required to "upgrade" the specific broken package, eg:

```
morpheus ~ # emerge -pv sys-devel/gcc

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ] sys-devel/gcc-4.5.3-r1  USE="cxx mudflap nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -fortran -gcj* -graphite -gtk* (-hardened) (-libffi) (-libssp) -lto (-multilib*) -multislot -nls -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

 * IMPORTANT: 6 news items need reading for repository 'gentoo'.

 * Use eselect news to read news items.
```

Before I started there were some additional packages, so I you need to try and match CFLAGS, as well as USE actually (which I did not, which is why the gcj and gtk flags above is wrong now, also laptop is multilib which the server is not.  So on the laptop I then executed:

```
CFLAGS="-O2 -mcpu=core2 -mcx16 -msahf -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -march=core2" emerge -1avB =dev-libs/mpc-0.8.2 =sys-devel/gcc-4.5.3-r1 ...
```

From there you can copy the binary packages (now residing in /usr/portage/packages probably) over to the other system using whatever mechanism you prefer, I like rsync:

```
# rsync -rvP /usr/portage/packages/ root@remsystem:/usr/portage/packages/
```

Then on the broken system:

```
# emerge -Kav sys-devel/gcc
```

Which should now insist it wants to install a bunch of BINARY packages.  If so, proceed, and you should now have a fully functional system again.  Obviously this assumes your python is still OK.  If not, well, good luck, I believe there are some recovery tarballs you can use in those cases, but generally it's a harder problem to solve.

----------

## Alakhai

Thanks it worked for me!

----------

