Multilib migration after The Great Merge (optional)
Disclaimer: The entire migration procedure as described below is completely optional. If you don’t need or want multilib/multibuild/multiple C targets support, you can ignore this email.
We won’t force anyone to use it. I’m only going to use it on my desktop myself. 🙂
We’ve now merged all multilib branches into master (this will go down into history books as “The Great Merge”!).
Thus, we don’t have any separate branches in our official and dev repositories anymore and if you still have a multilib branch in your repository, please merge it, too.
Now is a good time to write an updated multilib migration guide so, without further ado, here we go:
- Switch to the multibuild profile in arbor.conf (${location}/profiles/amd64/multilib)
- Ensure that CHOST is not set in bashrc, and note that CFLAGS will apply to all C targets. You can use MULTIBUILD_C_{32,64}_USER_C{,XX}FLAGS for individual C targets.
- Re-install/update sys-apps/skeleton-filesystem-layout
- Install sys-libs/glibc[bootstrap], note that this should pull in sys-devel/bootstrap-gcc, too. (This is going to take a long time.)
- Install sys-devel/gcc[-openmp] (This is potentially going to take a long time, especially if you have the java option set.)
- Use eclectic gcc to switch to the freshly compiled multilib gcc
- Install sys-libs/glibc[-bootstrap], you can let Paludis purge sys-devel/bootstrap-gcc while doing so.
- Adjust your options to include the C targets you want and re-install any packages accordingly.
You might have to re-install lots of package dependencies to fulfill a newly selected target’s requirements. (I simply did a cave resolve -e world)
Best regards, Wulf
I am and have been working on quite a few F/OSS projects: |
Is that *real* multilib support? Looks like my only excuse for still using Gentoo is inertia.
Yes, it is. Real, native multilib support.
Nice news, in this case i can install it on my machine as productive OS.