Passing -C panic=abort still attempts to link in libunwind when targeting i686-pc-windows-gnu on v1.44+
#79609
Comments
This is required because of a regression in the `Rust` build on i686-w64-mingw32: rust-lang/rust#79609
This is required because of a regression in the `Rust` build on i686-w64-mingw32: rust-lang/rust#79609
* Roll `Rust` build back to `v1.43` This is required because of a regression in the `Rust` build on i686-w64-mingw32: rust-lang/rust#79609 * Bump hardcoded version number
|
Having a similar problem at the moment. Not sure if this is an acceptable solution for you, but using rust-embedded/cross to build for (Although I had some issues with installing it through cargo. Instead, clone it, run the docker image building script for the |
For me it's not because our entire ecosystem is based on mingw32 using SJLJ, rather than dwarf2, and I don't believe you can mix those two within a single process (e.g. loading those rust-built libraries within a C++ process that uses a different exception style). |
|
@rustbot modify labels: regression-untriaged |
rustbot
added
regression-untriaged
LeSeulArtichaut
added
regression-from-stable-to-stable
camelid
added
A-cross
|
Assigning |
apiraino
added
P-high
|
Adding |
|
I just tested this, and using LTO on Rust 1.48.0 (or 1.49.0) does not solve these errors for me. Here is example output while compiling Perhaps this works for simpler packages, but for more complex things, it doesn't appear to properly eliminate the dependency on |
|
same problem my temporary solution cargo +1.43.0 build --target=i686-pc-windows-gnu |
|
Debug can't compile, while release can. |
|
Hi all, this issue has remained open for a number of releases now and is preventing us from using Rust > 1.43.0 in Prince. What would be the best way to help find a solution? I'm not sure I am in position to find and fix the issue myself (due to my lack of experience working on the compiler) but I could try to bisect changes to work out what change introduced the issue, or something like that if it will help. |
|
In case it's helpful here's a FROM rust:1.51-slim-buster
RUN apt-get update && \
apt-get install -y --no-install-recommends gcc-mingw-w64-i686
RUN rustup target add i686-pc-windows-gnu
RUN echo "fn main() {\nprintln!(\"Hello, Windows!\");\n}" > hello_world.rs && \
rustc --target=i686-pc-windows-gnu -C panic=abort -o hello_world.exe hello_world.rsBuild that image with: |
rustbot
added
the
ICEBreaker-Cleanup-Crew
|
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good cc @AminArria @camelid @chrissimpkins @contrun @DutchGhost @elshize @ethanboxx @h-michael @HallerPatrick @hdhoang @hellow554 @henryboisdequin @imtsuki @JamesPatrickGill @kanru @KarlK90 @LeSeulArtichaut @MAdrianMattocks @matheus-consoli @mental32 @nmccarty @Noah-Kennedy @pard68 @PeytonT @pierreN @Redblueflame @RobbieClarken @RobertoSnap @robjtede @SarthakSingh31 @shekohex @sinato @smmalis37 @steffahn @Stupremee @tamuhey @turboladen @woshilapin @yerke |
|
To be fair this issue was specifically about SLJL mingw32 whereas the "fix" in v24 drops SLJL for Dwarf2; I should have called it a "workaround" instead, sitting alongside @Amanieu's alternative suggestion of using |
|
As a workaround you could just define your own |
Bumping as this is still reproducible with the latest stable: but fixed with: |
|
I don't think this issue can be fixed. The only solutions are:
|
On some targets, alloc is built with unwinding. Therefore, it requires libunwind even when compiling with panic=abort. Defining the _Unwind_Resume symbol fixes this. The actual implementation does not matter, since it will never be called. See rust-lang/rust#79609 for more details.
On some targets, alloc is built with unwinding. Therefore, it requires libunwind even when compiling with panic=abort. Defining the _Unwind_Resume symbol fixes this. The actual implementation does not matter, since it will never be called. See rust-lang/rust#79609 for more details.
I'm trying to cross compile to i686-pc-windows-gnu from Linux (Ubuntu 20.04) using rust 1.61. Following the preceding advise, I'm adding this to my main binary: #[no_mangle]
pub extern "C" fn _Unwind_Resume() {}And it is indeed working. Thanks! |
|
Visiting for P-high review. From the discussion here, it seems like finding a seamless solution to this problem is either hard or impossible. the right long-term solution may involve some form of but any solution here is probably going to require post-processing of the linker-failure (including its stack trace), pattern matching for the "undefined reference to `_Unwind_Resume'" and then giving guidance as to what workarounds the user can use in response. |
This fixes building with llvm-mingw for i686 (which uses dwarf for unwinding on i686) after updating to Rust 1.65.0 in cb4464d. The problematic patch was needed for fixing build breaks with mingw toolchains that use SjLj exception handling (which is what is used in VLC's current CI builds for mingw/i686) - which is rust-lang/rust#79609. Rust's stdlib contains references to the _Unwind_Resume symbol (which is what the symbol is called in dwarf unwinding cases), but it's not meant to actually be called (since rav1e is built with "-C panic=abort"). If the mingw toolchain itself uses dwarf (or SEH) unwinding, then the _Unwind_Resume symbol is provided from that unwinder. But in the case of SjLj toolchains, the toolchain only provides a symbol named __Unwind_SjLj_Resume. The patch provided a dummy _Unwind_Resume symbol as part of the rav1e build, which fixed the undefined references with SjLj toolchains. However, since updating to Rust 1.65.0, other object files in the Rust stdlib seems to pull in more unwinding symbols (there are undefined references to e.g. _Unwind_GetRegionStart). These other symbols are named the same both in dwarf, SjLj and SEH toolchains. In the case of SjLj toolchains, they ended up pulled in from libunwind/libgcc, but in the case of dwarf or SEH toolchains, the locally defined _Unwind_Resume caused a conflict with the real one which ended up included from libunwind/libgcc. To avoid the issue, provide all referenced symbols as similar stubs; this makes sure that the build doesn't end up pulling in anything unwinding related from libunwind/libgcc, either in SjLj or dwarf toolchains.
|
I may have aimed a bit too high in my ideas in my previous comment from 2022-12-02. A much easier answer is to add an entry for i686-pc-windows-gnu to https://doc.rust-lang.org/rustc/platform-support.html , document this there, and point this issue at those docs (so that people googling about this will end up there eventually) |
Noratrieb
added
O-x86_32
Enselic
added
O-windows
Summary
When cross-compiling from a Linux distribution that provides SLJL mingw32, linker errors about
libunwindsymbols are a known issue (#12859). The generally-accepted workaround is to disable exception handling (via-C panic=abort) which should disable the need to collect backtraces and eliminate the linker errors. This works on a 1.43.0 toolchain, but is broken on 1.44.0-1.48.0Example of error
Here's an example of the error, running within the
BinaryBuilder.jlcross-compilation environment.Testing with multiple versions
I use the following script to install new versions of
rustc:Version it worked on
This works on Rust 1.43.0.
Version with regression
This does not work on Rust 1.44.0-1.48.0
The text was updated successfully, but these errors were encountered: