jrtc27 added a comment. In D98113#2872080 <https://reviews.llvm.org/D98113#2872080>, @jroelofs wrote:
>> compiler-rt depends on a libc, typically newlib, which then depends on your >> compiler > > The builtins should only depend on compiler-provided headers, and not on the > rest of libc. Agreed re: the rest of compiler-rt. Until recently builtins required libc headers, though we upstreamed a patch to remove that dependency. In D98113#2872079 <https://reviews.llvm.org/D98113#2872079>, @jroelofs wrote: > Why do you want to ship the builtins as part of your sysroot? Several reasons off the top of my head: 1. There's no general way to have multiple ABIs/ISA variants co-exist for the same base ISA. We have aarch64, mips64, riscv32 and riscv64 as architectures we support, and each of those has three different variants we need (two with different ISA baselines, one with a whole different ABI). 2. We build LLVM once and then use that same toolchain for multiple architectures. Whilst, with sufficient general multilib/multiarch support across all architectures, that could be supported, it means that either you need to provide a toolchain that has binaries built for all architectures (despite the fact that most of our users only want one or two), or you need to provide multiple copies of LLVM with different sets of libs bundled in the same directory. Moreover, your toolchain might be in a shared read-only directory (NFS or similar), installed by your sysadmin or who knows what else, with you unable to modify it. This allows you to use that toolchain to build whatever software you like, as you can point it at whatever sysroot you've created with whatever compiler-rt you want, rather than having to ask your sysadmin to install a specific version of compiler-rt in a global namespace. 3. If people hard-code -lgcc in their Makefiles then distributing the run-time support library (be it a renamed compiler-rt or libgcc) in a sysroot works out of the box. If you want to then give libclang_rt.builtins its "proper" name, and switch the Makefile to use -print-libgcc-file-name rather than hard-coding -lgcc, this suddenly breaks, as -print-libgcc-file-name falls back on giving you the absolute path to where the builtins library would live in the resources directory. This incentivises people to do the wrong thing (hard-code -lgcc and rename their libclang_rt.builtins to libgcc) in order to make things work. 4. If -lclang_rt.builtins-riscv64 works just fine, finding the library as normal in the library search path, why shouldn't -print-libgcc-file-name? Hard-coding -lclang_rt.builtins-ARCH in your Makefile is bad practice just like hard-coding -lgcc (maybe it's fine in your internal project, but not if it's general open-source software that needs to support GCC and Clang in a wide variety of configurations), yet also works, so again incentivises bad practices / penalises doing the right thing. 5. When targeting FreeBSD, compiler-rt lives in the sysroot (FreeBSD's base system vendors it), this allows the same model to be used for bare-metal sysroots. Overall, my view is this provides flexibility that aligns much more nicely with our build system and software distribution model with little added complexity to Clang and should not break any existing uses. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98113/new/ https://reviews.llvm.org/D98113 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
