Repository navigation
1.46.0 fails to build with llvm-libunwind enabled #76020
Description
On one of my systems which is entirely based on llvm/clang/libc++/llvm-libunwind 1.46.0 builds fine, but on the other "traditional" ones, it fails with
error: linking with `/usr/host/bin/x86_64-pc-linux-gnu-cc` failed: exit code: 1
|
= note: "/usr/host/bin/x86_64-pc-linux-gnu-cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/var/tmp/paludis/build/dev-lang-rust-1.46.0/work/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib64/rustlib/x86_64-unknown-linux-gnu/lib" "/var/tmp/paludis/build/dev-lang-rust-1.46.0/work/rustc-1.46.0
-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/rustc_binary-7b7ea85adaabb772.rustc_binary.4nmnfy3t-cgu.0.rcgu.o" "/var/tmp/paludis/build/dev-lang-rust-1.46.0/work/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/rustc_binary-7b7e
a85adaabb772.rustc_binary.4nmnfy3t-cgu.1.rcgu.o" "-o" "/var/tmp/paludis/build/dev-lang-rust-1.46.0/work/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/rustc_binary-7b7ea85adaabb772" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-Wl,-O1" "-nodefaultlibs" "-L"
"/var/tmp/paludis/build/dev-lang-rust-1.46.0/work/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps" "-L" "/var/tmp/paludis/build/dev-lang-rust-1.46.0/work/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps" "-L" "/var/tmp/paludis/build/dev-lang-r
ust-1.46.0/work/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/build/jemalloc-sys-741a979a41c097fb/out/build/lib" "-L" "/var/tmp/paludis/build/dev-lang-rust-1.46.0/work/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/build/psm
-434df6e9150bc0ba/out" "-L" "/var/tmp/paludis/build/dev-lang-rust-1.46.0/work/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/build/rustc_llvm-37977d896f0c1d8a/out" "-L" "/usr/x86_64-pc-linux-gnu/lib/llvm/10/lib" "-L" "/var/tmp/paludis/build/dev-lang-rust-1.46.0/work/rustc
-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib64/rustlib/x86_64-unknown-linux-gnu/lib" "-L" "/var/tmp/paludis/build/dev-lang-rust-1.46.0/work/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps" "-lrustc_driver-ca92058eee3505a8" "-Wl,-Bstatic" "/var/tmp/paludis/build/dev-lang-rust-1.46.0/work/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libjemalloc_sys-40622d79400e9af9.rlib" "-Wl,--start-group" "-L" "/var/tmp/paludis/build/dev-lang-rust-1.46.0/work/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib64/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bdynamic" "-lstd-230cc113f5bd99f4" "-Wl,--end-group" "-Wl,-Bstatic" "/var/tmp/paludis/build/dev-lang-rust-1.46.0/work/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib64/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-5c27ddf29299677e.rlib" "-Wl,-Bdynamic" "-lz" "-lrt" "-ldl" "-ltinfo" "-lpthread" "-lm" "-lxml2" "-lstdc++" "-lpthread" "-lutil" "-ldl" "-lutil" "-ldl" "-lrt" "-lpthread" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-ldl" "-lutil" = note: /usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ld: /var/tmp/paludis/build/dev-lang-rust-1.46.0/work/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_driver-ca92058eee3505a8.so: undefined reference to `_Unwind_Resume'
/usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ld: /var/tmp/paludis/build/dev-lang-rust-1.46.0/work/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_driver-ca92058eee3505a8.so: undefined reference to `_Unwind_GetIP'
/usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ld: /var/tmp/paludis/build/dev-lang-rust-1.46.0/work/rustc-1.46.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_driver-ca92058eee3505a8.so: undefined reference to `_Unwind_Backtrace'
collect2: error: ld returned 1 exit status
1.45.2 compiles fine.
I'm currently doing some testing but I suspect that 21abc88 is the culprit
Activity
Keruspe commentedon Aug 28, 2020
I can confirm that reverting #72746 fixes the build
tmandry commentedon Sep 3, 2020
Can you provide more details about how you're building Rust? Are you using out-of-tree LLVM?
Keruspe commentedon Sep 4, 2020
I package rust for Exherbo (source-based) and I build it using its package manager.
For stable rust, we use the system llvm by default indeed
Keruspe commentedon Sep 23, 2020
@tmandry How can we get this to move forward?
I don't know how to reproduce the initial issue to find another fix but the current one is either wrong on incomplete given this failure
petrhosek commentedon Oct 8, 2020
The use case that was addressed by #72746 is mixing C++ and Rust code in a single process. In those cases, we don't want libunwind that's linked into Rust binaries to preempt libunwind symbols of C++ binaries because the two unwinders may be incompatible. This is particularly problematic when libunwind used by C++ is sanitized but Rust one isn't which leads to runtime failure that we observed in Fuchsia.
The solution is to build libunwind as a hermetic library to avoid re-exporting its symbols. We already use
-fvisibility=hiddenwhen building libunwind but that doesn't take effect unless we disable visibility annotations which is what #72746 does.I haven't managed to reproduce this failure locally, but my guess is that in your build
librustc_driverdoesn't explicitly link unwinder and instead relies on unwinder symbols being provided transitively by some other library. After #72746, those symbols are no longer exported hence the link failure. If that's indeed the case, then I think the correct solution isn't to revert that change but to find out why unwinder isn't being linked explicitly.Keruspe commentedon Oct 8, 2020
Could this be somehow related to the use of
-Wl,--as-needed?Keruspe commentedon Oct 8, 2020
It is not, just retries disabling it.
The failing linker invocation is:
Looks like rustc adds some
--as-neededeven if it's not in LDFLAGS.Let's get the interesting part out of this:
I don't see any "-lunwind" in the linker arguments, or am I missing something here?
Keruspe commentedon Oct 8, 2020
I see in the logs
libunwind-32bae9364f36982a.rmetabeing mentioned during builds of panic_unwind, andlibunwind-32bae9364f36982a.rlibbeing mentioned during builds of std.-lunwindnever appears.@petrhosek when and how is this linkage supposed to happen?
Keruspe commentedon Oct 8, 2020
Inside libstd.so I see the two "missing" symbols:
mati865 commentedon Oct 8, 2020
@Keruspe can you look for the same symbols in
librustc_driver*.so?Keruspe commentedon Oct 8, 2020
mati865 commentedon Oct 8, 2020
@petrhosek IIUC before #72746 when
rust.llvm-libunwindin theconfig.tomlwas enabled, whole libunwind was reexported bylibstd-<hash>.so(this option disables linking unwind library from the system) which is not essentially correct.We reexport necessary symbols for our use here so
librustc_driver_<hash>.soshould have those symbols provided bylibstd-<hash>.so.Does this sound right?
My gut says it's BFD vs LLD difference but I cannot test it soon.
Keruspe commentedon Oct 8, 2020
Testing with lld
Keruspe commentedon Oct 8, 2020
Same error with lld and bfd.
I've come to the same understanding as you, fwiw. And since rustc_driver doesn't list the unwind crate in its dependencies, I fail to see how it could get the symbols the same way std does.
Maybe when building rust with the system llvm and with llvm-libunwind enabled we should dynamically link to the system llvm-libunwind instead?
6 remaining items
petrhosek commentedon Oct 13, 2020
I think I understand the problem is now. We build both static and shared version libstd, but should be only using the hermetic unwinder for the static version, for shared version we should be using the non-hermetic one because the shared library is expected to re-export unwinder API.
mati865 commentedon Oct 13, 2020
Sounds plausible to me.
Rollup merge of rust-lang#77703 - Keruspe:system-libunwind, r=Mark-Si…
John-Nagle commentedon Mar 12, 2022
Bug seems to be back. See #77394
jyn514 commentedon Mar 12, 2022
cc @jonhoo, this might be related to #94719
jonhoo commentedon Mar 12, 2022
Hmm, that's 1.59.0, which doesn't have any of my changes around linking in it. Though it could be they my change will fix it I suppose 😅
John-Nagle commentedon Mar 12, 2022
Try this on Linux with your version, to check, please.
This will build on Linux with a Linux target, but not with a i686-pc-windows-gnu target.
jonhoo commentedon Mar 12, 2022
If you want to test it with my various fixes around linker flags, those should all be active on nightly I think. Or possibly tomorrow's nightly.
John-Nagle commentedon Mar 12, 2022
No joy. Just downloaded nightly.
rustc --version
rustc 1.61.0-nightly (335ffbf 2022-03-11)
still fails with the linker unable to find `_Unwind_Resume'.
Full compile listing.
unwindbug01.txt
jonhoo commentedon Mar 12, 2022
I think you may need today's nightly to get my latest fix. Though I still don't know that my changes would actually fix this issue — this doesn't feel related to whether libstdc++ is statically compiled.
John-Nagle commentedon Mar 12, 2022
OK. Nightly hasn't updated yet. Still "rustc 1.61.0-nightly (335ffbf 2022-03-11)". I'll try later.
John-Nagle commentedon Mar 13, 2022
Nightly has updated to rustc 1.61.0-nightly (f103b29 2022-03-12).
Same problem:
undefined reference to_Unwind_Resume'` Compile log attached.unwindbug02.txt
But I was building for a Windows 32 bit target, which nobody cares about much any more. That doesn't work.
If i build for a Windows 64 bit target, it works. Which is what I really need. Thanks.
mati865 commentedon Mar 13, 2022
@John-Nagle this issue is for building Rust with specific config option not using it.
It is tested every time PR is merged.
I think you are building on Ubuntu 20.04 which ships SLJL exceptions rateher than Dwarf for i686. AFAIK this is fixed in newer Ubuntu releases.
jyn514 commentedon Feb 3, 2023
I'm going to close this since it sounds like the original issue is fixed.