User:Immolo/Fix broken compiler
Sometimes as Gentoo users, it's possible to have an Icarus moment when testing very new compiler versions, which can leave the user's system unable to compile. This article will show some of the ways to get a working compiler back on the system when a restored backup won't fix the issue.
LLVM
GCC Repair Solution
If the system still has a working GCC toolchain then this is then using that is the easiest way to get LLVM working again.
Switch Profile
This section is only needed if you are using an LLVM profile otherwise it can be skipped.
root #
eselect profile list
In this example the system is using [33] default/linux/amd64/17.0/musl/clang
so to switch to a GCC profile select the profile that matches your current system just without the clang
part of the profile.
root #
eselect profile default/linux/amd64/17.0/musl
This step makes sure all the correct USEFLAGS are set to minimise any issues during the repair.
Building LLVM
GCC currently causes an ICE in any version before LLVM-17 if compiled with -flto so make sure it is removed if used on the system during this section.
Now to compile a LLVM that will work again.
root #
emerge --ask sys-devel/clang sys-devel/llvm sys-libs/compiler-rt sys-libs/llvm-libunwind sys-devel/lld
If needed, switch back to the clang profile:
root #
eselect profile set --force default/linux/amd64/17.0/musl/clang
After this it is recommended to rebuild LLVM with itself using:
root #
emerge --ask sys-devel/clang sys-devel/llvm sys-libs/libcxx sys-libs/libcxxabi sys-libs/compiler-rt sys-libs/llvm-libunwind sys-devel/lld
Rescue Chroot Solution
This solution is recommended for those who wish to run a pure LLVM system using LLVM's libcxx. Linking the compiler against GCC's version may result in ABI-incompatible toolchain components
This solution will rely on the usage of a stage archive to build a binary package for the main machine.
Preparing the Environment
Create a chroot directory in an accessible place.
user $
mkdir -p rescue_chroot
Download an appropriate stage tarball from a mirror
user $
wget <PASTED_STAGE_URL>
Extract the tarball to the appropriate directory.
root #
tar xpvf stage3-amd64-llvm-*tar.xz --xattrs-include="*.*" --numeric-owner -C rescue_chroot
In order for the binpkg to act as a drop-in replacement, the USE flags between the main system and the rescue chroot need to match up.
One way to accomplish this would be to copy over the related files
root #
cp /etc/portage/make.conf rescue_chroot/etc/portage
root #
cp -r /etc/portage/package.use rescue_chroot/etc/portage/package.use
Copy over resolv.conf to allow networking
root #
cp /etc/resolv.conf rescue_chroot/etc
Entering the Environment and Installing the Packages
Mount the necessary filesystems
root #
mount --types proc /proc rescue_chroot/proc
root #
mount --rbind /sys rescue_chroot/sys
root #
mount --make-rslave rescue_chroot/sys
root #
mount --rbind /dev rescue_chroot/dev
root #
mount --make-rslave rescue_chroot/dev
root #
mount --bind /run rescue_chroot/run
root #
mount --make-slave rescue_chroot/run
Chroot into the system
root #
chroot rescue_chroot /bin/bash --login
root #
export PS1="(rescue) ${PS1}"
Installing the new packages
Firstly, we must sync the repos
root #
emerge-webrsync
Confirm the profile is set to clang
root #
eselect profile list
By parsing the --buildpkg option to emerge we may now build packages for our host machine
chroot
emerge --buildpkg sys-devel/clang sys-devel/llvm sys-libs/libcxx sys-libs/libcxxabi sys-libs/compiler-rt sys-libs/llvm-libunwind sys-devel/lld sys-libs/compiler-rt-sanitizers
Exit the chroot
chroot
exit
Completing the rescue process, we may now install the binary packages on our host machine
root #
PKGDIR="PATH_TO_RESCUE_CHROOT/var/cache/binpkgs" emerge --usepkgonly --oneshot sys-devel/clang sys-devel/llvm sys-libs/libcxx sys-libs/libcxxabi sys-libs/compiler-rt sys-libs/llvm-libunwind sys-devel/lld sys-libs/compiler-rt-sanitizers
See also
- Fix my Gentoo — rescuing an installation when a chroot is not possible