Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 733242 - dev-lang/rust: Link against llvm-libunwind in case of using clang with compiler-rt and if it's installed (link to gcc_s if not installed)
Summary: dev-lang/rust: Link against llvm-libunwind in case of using clang with compil...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Georgy Yakovlev
URL:
Whiteboard:
Keywords: EBUILD, PATCH
: 834574 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-07-19 19:52 UTC by David Carlos Manuelda
Modified: 2022-09-16 00:50 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Diff to current 1.44.1 ebuild (rust-1.44.1.ebuild.diff,1.59 KB, patch)
2020-07-19 19:54 UTC, David Carlos Manuelda
Details | Diff
Diff to current 1.45.0 ebuild (rust-1.45.0.ebuild.diff,929 bytes, patch)
2020-07-19 19:54 UTC, David Carlos Manuelda
Details | Diff
diff to current 1.50.0 ebuild (rust-1.50.ebuild.diff,933 bytes, patch)
2021-03-02 08:02 UTC, David Carlos Manuelda
Details | Diff
diff to current 1.50.0 ebuild (rust-1.50.ebuild.diff,1.01 KB, patch)
2021-03-02 08:18 UTC, David Carlos Manuelda
Details | Diff
Fixed diff to 1.50.0 ebuild (rust-1.50.0.ebuild.diff,1.02 KB, patch)
2021-03-02 10:43 UTC, David Carlos Manuelda
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Carlos Manuelda 2020-07-19 19:52:13 UTC
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
Comment 1 David Carlos Manuelda 2020-07-19 19:54:09 UTC
Created attachment 649880 [details, diff]
Diff to current 1.44.1 ebuild
Comment 2 David Carlos Manuelda 2020-07-19 19:54:29 UTC
Created attachment 649882 [details, diff]
Diff to current 1.45.0 ebuild
Comment 3 Georgy Yakovlev archtester gentoo-dev 2020-07-24 05:54:21 UTC
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.
Comment 4 David Carlos Manuelda 2020-07-24 06:20:56 UTC
(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!
Comment 5 Perfect Gentleman 2020-10-13 06:08:17 UTC
There is problem with that llvm-libunwind. It can be used only without system-llvm.
Comment 6 12101111 2020-10-14 07:18:19 UTC
(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.
Comment 7 Oleh 2020-12-21 05:57:32 UTC
(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 :)
Comment 8 12101111 2021-01-08 17:58:36 UTC
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
Comment 9 Oleh 2021-01-12 14:41:14 UTC
i rather meant, how did you achieve musl+clang without gcc/glibc system, any steps?
Comment 10 Oleh 2021-01-12 16:57:32 UTC
without gcc*, glibc was a mistake, it make no sense on musl system :)
Comment 11 12101111 2021-01-13 06:19:48 UTC
(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
Comment 12 David Carlos Manuelda 2021-03-02 08:02:41 UTC
Created attachment 688983 [details, diff]
diff to current 1.50.0 ebuild

Diff to current 1.50.0 ebuild
Comment 13 David Carlos Manuelda 2021-03-02 08:18:20 UTC
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)
Comment 14 David Carlos Manuelda 2021-03-02 10:43:15 UTC
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)
Comment 15 Georgy Yakovlev archtester gentoo-dev 2021-06-10 22:52:55 UTC
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
Comment 16 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-03-05 07:44:50 UTC
*** Bug 834574 has been marked as a duplicate of this bug. ***
Comment 17 Larry the Git Cow gentoo-dev 2022-09-15 03:15:51 UTC
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(-)
Comment 18 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-09-16 00:50:23 UTC
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>