Currently, rust fails to build with clang and compiler-rt (also with libc++ instead of libstdc++) because of undefined references related to unwind (gcc_s or llvm-libunwind). The provided patches for the ebuild will link against llvm-libunwind (or gcc_s if not found) when compiling with clang and compiler-rt, and are transparent and noop for the rest of users. Reproducible: Always
Created attachment 649880 [details, diff] Diff to current 1.44.1 ebuild
Created attachment 649882 [details, diff] Diff to current 1.45.0 ebuild
thanks for patches. need to think about it. 1) it introduces magic dependency on sys-libs/llvm-libunwind and can't be merged as is. 2) in the following line > local compiler_rt=$($(tc-getCC) ${CPPFLAGS} ${CFLAGS} ${LDFLAGS} -print-libgcc-file-name) is using all the flags really necessary? I don't have alot of experience with clang/compiler_rt/libcxx toolchain and don't know all the gotchas yet, just asking. let me think on how to solve #1. bug 732632 is also somewhat related so those changes can be grouped together.
(In reply to Georgy Yakovlev from comment #3) > thanks for patches. need to think about it. > > 1) it introduces magic dependency on > sys-libs/llvm-libunwind > and can't be merged as is. > > 2) in the following line > > local compiler_rt=$($(tc-getCC) ${CPPFLAGS} ${CFLAGS} ${LDFLAGS} -print-libgcc-file-name) > > is using all the flags really necessary? I don't have alot of experience > with clang/compiler_rt/libcxx toolchain and don't know all the gotchas yet, > just asking. > > > > > let me think on how to solve #1. bug 732632 is also somewhat related so > those changes can be grouped together. 1) I know, but unfortunatelly I know no way of putting a dependency based on such condition, and a USE flag seems not the way to go (?) 2) I guess only LDFLAGS in case, for example, compiler-rt is default but other thing is stablished in flags, they do not harm anyway. Regarding bug #732632 I can say that with this patches, and clang-10 with libc++ and compiler-rt I was able to build both versions, even with system-bootstrap enabled (also in my case with parallel-compiler and nightly enabled). I recommend at least testing this patches, as it should solve mentioned bug also, then make a proper fix for it (as the automagic dep). Thanks for taking your time into looking for this!
There is problem with that llvm-libunwind. It can be used only without system-llvm.
(In reply to Perfect Gentleman from comment #5) > There is problem with that llvm-libunwind. It can be used only without > system-llvm. I don't think there is any issue with llvm-libunwind and system-llvm. [I] dev-lang/rust Available versions: (stable) (~)1.34.2(stable/1.34)[2] 1.45.2(stable/1.45)^t 1.46.0(stable/1.46)^t [m](~)1.46.0(stable/1.46)^t[3] (~)1.47.0-r1(stable/1.47)^t{tbz2} (~)1.47.0-r1(stable/1.47)^t{tbz2}[1] [m](~)1.47.0-r1(stable/1.47)^t{tbz2}[3] {clippy debug default-libcxx doc libressl miri nightly parallel-compiler rls rustfmt (+)system-bootstrap system-llvm test wasm ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32" CPU_FLAGS_X86="sse2" LLVM_TARGETS="AArch64 AMDGPU ARM AVR BPF Hexagon Lanai MSP430 Mips NVPTX PowerPC RISCV Sparc SystemZ WebAssembly X86 XCore"} Installed versions: 1.47.0-r1(stable/1.47)^t{tbz2}[1](20:16:17 10/13/20)(clippy default-libcxx miri nightly parallel-compiler rls rustfmt system-bootstrap system-llvm wasm -debug -doc -libressl -test ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" CPU_FLAGS_X86="sse2" LLVM_TARGETS="AArch64 AMDGPU ARM RISCV WebAssembly X86 -AVR -BPF -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -Sparc -SystemZ -XCore") Homepage: https://www.rust-lang.org/ Description: Systems programming language from Mozilla > ldd /usr/bin/rustc-1.47.0 /lib/ld-musl-x86_64.so.1 (0x7fe0e86df000) librustc_driver-911d8a2e559e6ba4.so => /usr/lib/rust/lib/librustc_driver-911d8a2e559e6ba4.so (0x7fe0e4595000) libstd-0278db2ec3f4d110.so => /usr/lib/rust/lib/libstd-0278db2ec3f4d110.so (0x7fe0e43f0000) libc.so => /lib/ld-musl-x86_64.so.1 (0x7fe0e86df000) libLLVM-11libcxx.so => /usr/lib/llvm/11/lib/libLLVM-11libcxx.so (0x7fe0df913000) libc++.so.1 => /usr/lib/libc++.so.1 (0x7fe0df835000) libc++abi.so.1 => /usr/lib/libc++abi.so.1 (0x7fe0df7f7000) libunwind.so.1 => /usr/lib/libunwind.so.1 (0x7fe0df7ea000) libffi.so.7 => /usr/lib/libffi.so.7 (0x7fe0df7de000) libedit.so.0 => /lib/libedit.so.0 (0x7fe0df79c000) libz.so.1 => /lib/libz.so.1 (0x7fe0df77e000) libtinfo.so.6 => /lib/libtinfo.so.6 (0x7fe0df735000) This system even don't have gcc installed, only have llvm.
(In reply to 12101111 from comment #6) > (In reply to Perfect Gentleman from comment #5) > > There is problem with that llvm-libunwind. It can be used only without > > system-llvm. > > I don't think there is any issue with llvm-libunwind and system-llvm. > > [I] dev-lang/rust > Available versions: (stable) (~)1.34.2(stable/1.34)[2] > 1.45.2(stable/1.45)^t 1.46.0(stable/1.46)^t [m](~)1.46.0(stable/1.46)^t[3] > (~)1.47.0-r1(stable/1.47)^t{tbz2} (~)1.47.0-r1(stable/1.47)^t{tbz2}[1] > [m](~)1.47.0-r1(stable/1.47)^t{tbz2}[3] > {clippy debug default-libcxx doc libressl miri nightly > parallel-compiler rls rustfmt (+)system-bootstrap system-llvm test wasm > ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32" > CPU_FLAGS_X86="sse2" LLVM_TARGETS="AArch64 AMDGPU ARM AVR BPF Hexagon Lanai > MSP430 Mips NVPTX PowerPC RISCV Sparc SystemZ WebAssembly X86 XCore"} > Installed versions: 1.47.0-r1(stable/1.47)^t{tbz2}[1](20:16:17 > 10/13/20)(clippy default-libcxx miri nightly parallel-compiler rls rustfmt > system-bootstrap system-llvm wasm -debug -doc -libressl -test ABI_MIPS="-n32 > -n64 -o32" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" CPU_FLAGS_X86="sse2" > LLVM_TARGETS="AArch64 AMDGPU ARM RISCV WebAssembly X86 -AVR -BPF -Hexagon > -Lanai -MSP430 -Mips -NVPTX -PowerPC -Sparc -SystemZ -XCore") > Homepage: https://www.rust-lang.org/ > Description: Systems programming language from Mozilla > > > ldd /usr/bin/rustc-1.47.0 > /lib/ld-musl-x86_64.so.1 (0x7fe0e86df000) > librustc_driver-911d8a2e559e6ba4.so => > /usr/lib/rust/lib/librustc_driver-911d8a2e559e6ba4.so (0x7fe0e4595000) > libstd-0278db2ec3f4d110.so => /usr/lib/rust/lib/libstd-0278db2ec3f4d110.so > (0x7fe0e43f0000) > libc.so => /lib/ld-musl-x86_64.so.1 (0x7fe0e86df000) > libLLVM-11libcxx.so => /usr/lib/llvm/11/lib/libLLVM-11libcxx.so > (0x7fe0df913000) > libc++.so.1 => /usr/lib/libc++.so.1 (0x7fe0df835000) > libc++abi.so.1 => /usr/lib/libc++abi.so.1 (0x7fe0df7f7000) > libunwind.so.1 => /usr/lib/libunwind.so.1 (0x7fe0df7ea000) > libffi.so.7 => /usr/lib/libffi.so.7 (0x7fe0df7de000) > libedit.so.0 => /lib/libedit.so.0 (0x7fe0df79c000) > libz.so.1 => /lib/libz.so.1 (0x7fe0df77e000) > libtinfo.so.6 => /lib/libtinfo.so.6 (0x7fe0df735000) > > This system even don't have gcc installed, only have llvm. how did you achieve this, any howto? Sorry for off-topic :)
I assume only system with musl (or maybe uclibc) can remove gcc without problem as clang can't compile glibc. However `llvm-libunwind=true` have no effect on musl system.See the code from library/unwind/build.rs: ``` let target = env::var("TARGET").expect("TARGET was not set"); if cfg!(feature = "llvm-libunwind") && ((target.contains("linux") && !target.contains("musl")) || target.contains("fuchsia")) { // Build the unwinding from libunwind C/C++ source code. llvm_libunwind::compile(); } else if target.contains("x86_64-fortanix-unknown-sgx") { llvm_libunwind::compile(); } else if target.contains("linux") { // linking for Linux is handled in lib.rs if target.contains("musl") { llvm_libunwind::compile(); } ``` if target is linux but not musl and enable llvm-libunwind feature, build.rs will compile in-tree libunwind, but if target is musl, build.rs will always compile in-tree libunwind even llvm-libunwind feature is disabled. And clang can't build in-tree libunwind here because build.rs will use CXX=clang to compile it. While gcc can compile it, clang will trigger an error: `invalid argument '-std=c++11' not allowed with 'C'`, see https://github.com/rust-lang/rust/issues/69222 ``` if target_env == "musl" { // use the same C compiler command to compile C++ code so we do not need to setup the // C++ compiler env variables on the builders cfg.cpp(false); // linking for musl is handled in lib.rs cfg.cargo_metadata(false); println!("cargo:rustc-link-search=native={}", env::var("OUT_DIR").unwrap()); } ``` To build rust with CC=clang and CXX=clang++, I use a patch here: https://github.com/12101111/overlay/blob/master/dev-lang/rust/files/musl-use-external-libunwind.patch rust 1.49.0 now allow link against system wide libunwind via llvm-libunwind=system, but still build.rs will build an in-tree copy on musl: https://github.com/rust-lang/rust/commit/66fa42a94627dc04de6d44227c5d06fec6b26d76
i rather meant, how did you achieve musl+clang without gcc/glibc system, any steps?
without gcc*, glibc was a mistake, it make no sense on musl system :)
(In reply to Oleh from comment #9) > i rather meant, how did you achieve musl+clang without gcc/glibc system, any > steps? https://wiki.gentoo.org/wiki/Clang#Bootstrapping_the_clang_toolchain Then rebuild everything, uninstall gcc, and replace elfutils with elftoolchain
Created attachment 688983 [details, diff] diff to current 1.50.0 ebuild Diff to current 1.50.0 ebuild
Created attachment 688986 [details, diff] diff to current 1.50.0 ebuild Diff to current 1.50.0 ebuild (updated to fix changes in toml config)
Created attachment 689055 [details, diff] Fixed diff to 1.50.0 ebuild Fixed a typo, tested, compiles and runs with clang(+default-compiler-rt,+default-libcxx)
clang added llvm-libunwind flag today. I was not closely tracking work being done here, due to automagic deps introduced by the patch. but with the useflag it can pull clang with proper flags, I believe. some info is here https://github.com/gentoo/gentoo/pull/19793
*** Bug 834574 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=55bc9f2304d70f79be3130b6ded482406b631958 commit 55bc9f2304d70f79be3130b6ded482406b631958 Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2022-09-15 02:51:02 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2022-09-15 02:55:01 +0000 dev-lang/rust: add llvm-libunwind handling in 1.63.0 tested working on clang-glibc-llvm system, untested on musl, but logic is the same as in PR 22221 Bug: https://bugs.gentoo.org/733242 PR: https://github.com/gentoo/gentoo/pull/22221 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> dev-lang/rust/rust-1.63.0.ebuild | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)
commit acacd8e179eb737f7e36c82ca6d8cf236eff0c9a Author: Sam James <sam@gentoo.org> Date: Fri Sep 16 00:19:40 2022 +0100 profiles: mask dev-lang/rust[llvm-libunwind] on non-LLVM profiles Doesn't work on e.g. glibc systems. Unmasked on the LLVM profiles. It doesn't matter much as llvm-libunwind has different semantics to other packages, i.e. -llvm-libunwind doesn't force use of sys-libs/libunwind on glibc, so it doesn't prevent usage of llvm-libunwind for other packages. Closes: https://bugs.gentoo.org/870211 Signed-off-by: Sam James <sam@gentoo.org>