1.46.0 fails to build with llvm-libunwind enabled #76020
Comments
|
I can confirm that reverting #72746 fixes the build |
|
Can you provide more details about how you're building Rust? Are you using out-of-tree LLVM? |
|
I package rust for Exherbo (source-based) and I build it using its package manager. |
|
@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 |
|
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 I haven't managed to reproduce this failure locally, but my guess is that in your build |
|
Could this be somehow related to the use of |
|
It is not, just retries disabling it. The failing linker invocation is: Looks like rustc adds some 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? |
|
I see in the logs @petrhosek when and how is this linkage supposed to happen? |
|
Inside libstd.so I see the two "missing" symbols: |
|
@Keruspe can you look for the same symbols in |
|
|
@petrhosek IIUC before #72746 when
My gut says it's BFD vs LLD difference but I cannot test it soon. |
|
Testing with lld |
|
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? |
|
#77703 fixes the build for me. Also, since I was using the system llvm, using the system llvm-libunwind makes sense too I think |
|
@petrhosek @mati865 do you suggest adding the unwind crate as a dependency for rustc_driver to properly fix the issue with in-tree llvm-libunwind? When attempting to do that, I ended up with errors about things not being Sized, I guess it's some kind of bootstrapping problem, not sure what to look for to fix this |
|
Btw, simple way to reproduce, copy config.toml.example as config.toml and just set llvm-libunwind to true, then |
That would solve the issue for rustc but everything else that links to libstd.so (tools, tests, ...) would fail. I'd be useful to know how Fuchsia differs from Linux here since this supposedly works there. I personally don't have time to investigate this issue. |
Fixes rust-lang#76020 Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
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. |
|
Sounds plausible to me. |
…mulacrum add system-llvm-libunwind config option allows using the system-wide llvm-libunwind as the unwinder Workaround for rust-lang#76020
|
Bug seems to be back. See #77394 |
|
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 😅 |
|
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. |
|
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. |
|
No joy. Just downloaded nightly. rustc --version still fails with the linker unable to find `_Unwind_Resume'. Full compile listing. |
|
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. |
|
OK. Nightly hasn't updated yet. Still "rustc 1.61.0-nightly (335ffbf 2022-03-11)". I'll try later. |
|
Nightly has updated to rustc 1.61.0-nightly (f103b29 2022-03-12). Same problem: But I was building for a Windows 32 bit target, which nobody cares about much any more. That doesn't work. |
|
@John-Nagle this issue is for building Rust with specific config option not using it.
It is tested every time PR is merged. |
I'm going to close this since it sounds like the original issue is fixed. |
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
1.45.2 compiles fine.
I'm currently doing some testing but I suspect that 21abc88 is the culprit
The text was updated successfully, but these errors were encountered: