@JustSoup321 had the idea of using an experimental new toolchain in postmarketOS. From pmbootstrap!2668: > * C Compiler: clang > * binutils: LLVM > * Linker: mold > > clang was chosen as the compiler because it is automatically a cross-compiler, removing the extra logic of building cross-compilers and packaging them in a way that makes sense to apk by manipulating the supported arches. > > LLVM was chosen as the binutils replacement because it works well with clang and properly cross-compiles. > > mold was chosen as the linker because it is more performant than lld in both native and cross-compilation. > > If `pmb:experimental-toolchain` is not added or `!pmb:experimental-toolchain` is added, then Alpine's `build-base` is installed and gcc + binutils are used as normal. ## Is this useful? ### Advantages We discussed this in chat, and I found it interesting to explore this. My hope is that it could simplify the cross compiler setup long term, which while it works most of the time, is hard to maintain and I personally end up spending a lot of time on it, which I can't use in other parts of the project: * Cross compiler GCCs get built from Alpine's gcc APKBUILD by doing several text replaces/inserts via e.g. `pmbootstrap aportgen gcc-aarch64`. * This is fragile and breaks when the Alpine GCC APKBUILD gets refactored. * The way it currently works is that we have ~40 patch files for each gcc + arch combination in pmaports. * It means manual steps are necessary whenever Alpine's gcc changes (even if it is a trivial change). (At least we have some [automatic CI tests](https://gitlab.postmarketos.org/postmarketOS/pmaports/-/blob/master/cross/.gitlab-ci.yml) now that ensure cross compilers actually work before merging, before that we had to do manual testing, which wasn't always documented properly and lead to errors that meant cross compilers broke in edge.) So if we could just scrap that at some point and use Alpine's clang to build all of our own packages, then it would save a lot of maintenance work. The linker is also currently very slow, especially when used through the ["crossdirect" method](https://docs.postmarketos.org/pmbootstrap/cross_compiling.html) where it must run through QEMU. If we could use mold instead (which is already supposed to be much faster), natively (!), we should see a significant speed improvement! ### Potential problems * Packages forked from Alpine (e.g. to enable systemd-specific stuff) may run into clang-specific compiler errors that we don't run into in Alpine. * Then again Chimera Linux is using a similar setup, musl libc + clang, llvm. If it works for them, and they are already upstreaming patches to fix stuff that breaks in this combination, it is likely that we won't run into that many issues? * Old kernels will not work with llvm without further patches. So we definitely need to keep some cross GCCs around for downstream kernels. But we could do e.g. major versions instead of following the current Alpine version all the time. We already have gcc4 and gcc6 packages, and these are close to zero effort to maintain because they don't change. ### My conclusion Personally I think it is worth doing this, as long as we introduce it as opt-in, test it to the point that we can build all packages (except for downstream kernels?) with this, and then make it opt-out. I might be missing something though, so happy to hear from others about this. ## Related MRs * https://gitlab.postmarketos.org/postmarketOS/pmbootstrap/-/merge_requests/2668 * https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6918