To support x86_32 clang on x86_64, the following abi_x86_32 ABIs are turned on in profiles/arch/amd64/package.use: # Theo Anderson <telans@posteo.de> (2021-03-06) # Enable 32-bit clang runtime to ease -m32 builds with non-GCC runtime sys-devel/clang-runtime abi_x86_32 sys-libs/libcxxabi abi_x86_32 sys-libs/libcxx abi_x86_32 sys-libs/libomp abi_x86_32 sys-libs/llvm-libunwind abi_x86_32 However, sys-libs/libunwind may be used as an alternative to llvm-libunwind (and must be for unwind support in media-libs/mesa and media-gfx/gimp). The end result is that x86_32 clang gets built but won't run due to the missing x86_32 libunwind: /usr/lib/llvm/18/bin/i686-pc-linux-gnu-clang -O2 -pipe -march=native CMakeFiles/cmTC_05106.dir/testCCompiler.c.o -o cmTC_05106 && : ld.lld: error: unable to find library -lunwind ld.lld: error: unable to find library -lunwind The above was encountered when trying to compile sys-libs/libcxxabi (a dependency of clang-common if default-libcxx is set) but is also visible if /usr/lib/llvm/18/bin/i686-pc-linux-gnu-clang is run manually at the command line. Reproducible: Always Steps to Reproduce: 1. Set the USE flag 'default-libcxx' on clang-common on x86_64 2. Rebuild clang-common 3. Actual Results: sys-libs/libcxxabi fails to build due to the inconsistent abi_x86_32 usage (enabled for libcxxabi, but not libunwind) Expected Results: To make default-libcxx work, it was necessary to: 1. Add abi_x86_32 to sys-libs/libunwind and dependency app-arch/xz-utils 2. Build libcxx manually with a clang without USE="default-libcxx", otherwise the compiler can't find -lc++ (i.e. itself) 3. Build clang-common with USE="default-libcxx" 4. Test by rebuilding libcxx Portage 3.0.63 (python 3.11.9-final-0, default/linux/amd64/23.0/systemd, gcc-14, glibc-2.40-r5, 5.10.52-gentoo.hex x86_64) ================================================================= System uname: Linux-5.10.52-gentoo.hex-x86_64-AMD_Ryzen_9_3900X_12-Core_Processor-with-glibc2.40 KiB Mem: 65824120 total, 12058160 free KiB Swap: 124999672 total, 124999672 free Timestamp of repository gentoo: Thu, 05 Dec 2024 07:30:01 +0000 Head commit of repository gentoo: 1cde4cb77aa63d9edfbf346d80ae5785f8f4dd39 sh bash 5.2_p37 ld GNU ld (Gentoo 2.42 p6) 2.42.0 distcc 3.4 x86_64-pc-linux-gnu [disabled] app-misc/pax-utils: 1.3.7::gentoo app-shells/bash: 5.2_p37::gentoo dev-build/autoconf: 2.13-r7::gentoo, 2.69-r9::gentoo, 2.71-r6::gentoo dev-build/automake: 1.16.5::gentoo dev-build/cmake: 3.28.3::gentoo dev-build/libtool: 2.4.7-r4::gentoo dev-build/make: 4.4.1-r100::gentoo dev-build/meson: 1.3.2::gentoo dev-java/java-config: 2.3.3-r1::gentoo dev-lang/perl: 5.38.2-r3::gentoo dev-lang/python: 3.10.14_p1-r1::gentoo, 3.11.9-r1::gentoo, 3.12.3-r1::gentoo, 3.13.0::gentoo dev-lang/rust: 1.80.1-r100::gentoo, 1.81.0-r100::gentoo sys-apps/baselayout: 2.17::gentoo sys-apps/sandbox: 2.29::gentoo sys-apps/systemd: 255.7-r1::gentoo sys-devel/binutils: 2.38-r2::gentoo, 2.40-r5::gentoo, 2.42-r2::gentoo, 2.43-r2::gentoo sys-devel/binutils-config: 5.3.2::gentoo sys-devel/clang: 15.0.7-r1::gentoo, 16.0.6::gentoo, 17.0.6::gentoo, 18.1.8::gentoo sys-devel/gcc: 11.5.0::gentoo, 12.4.1_p20241114::gentoo, 13.3.1_p20241115::gentoo, 14.2.1_p20241116::gentoo sys-devel/gcc-config: 2.11::gentoo sys-devel/lld: 15.0.7::gentoo, 17.0.6::gentoo, 18.1.8::gentoo sys-devel/llvm: 14.0.6-r2::gentoo, 15.0.7::gentoo, 16.0.6::gentoo, 17.0.6::gentoo, 18.1.8-r4::gentoo sys-kernel/linux-headers: 6.6::gentoo (virtual/os-headers) sys-libs/glibc: 2.40-r5::gentoo
If using default-libcxx, it's expected that: a) people accept things may well break, given it breaks ABI; b) people use the LLVM profiles which handle this But I also think this is really kind of obvious and for the user to handle if they start setting such things anyway. If they want the profile to handle it for them, they should use the profile designed for it (the LLVM one). default/linux/amd64/23.0/llvm/package.use.force:14:sys-libs/llvm-libunwind abi_x86_32 abi_x86_64
(In reply to Sam James from comment #1) > If using default-libcxx, it's expected that: > a) people accept things may well break, given it breaks ABI; > b) people use the LLVM profiles which handle this > > But I also think this is really kind of obvious and for the user to handle > if they start setting such things anyway. To elaborate a bit on this: we can't know what toolchain the user is using if they modify it -- which is their prerogative -- but we still can't know what they've chosen to set dependencies accordingly.
We could add libunwind in there but this then affects non-LLVM users when we'd expect them to be using the LLVM profile anyway. (... as libgcc(_s) handles this for those not using clang+compiler-rt).
Thanks for the explanation. I wasn't aware that these flags were experimental when I enabled them. It may be worth making this clearer or perhaps masking them outside the LLVM profiles. I wasn't aware of what the LLVM profiles did until I looked into them yesterday. I certainly don't want anything as extreme as building everything with the LLVM/clang stack. I turned the flags on because it sounded like they made that compiler stack more consistent with itself, but now I realised it actually creates risk in using a different ABI. I agree adding abi_x86_32 to unwind generally would have too much impact. It's still not clear to me why it is enabled on the other packages outside the LLVM profile, where unwind is the default and it causes breakage. It might also be worth moving them to the LLVM profile, if b) is the intention.
