Cross-compiling to Windows is broken #12859
Comments
|
It's not just clang! With gcc: |
|
This makes me think it's just wrongness. |
|
To reproduce: |
|
Also #11312, llvm-mc is borking on some of the assembly. |
|
When using the tripple In addition, for |
|
Nothing in the mingw-w64 distribution provides that symbol, and compiler-rt doesn't seem to either. What I get today: |
|
The |
|
Anything like this? http://stackoverflow.com/a/22774664 |
|
Compiling a C++ program that uses exceptions uses |
|
@bharrisau related but not quite the same, I think. |
|
The Arch pkgbuild indeed uses |
|
LLVM is converting |
|
Can we add some linker setting or a wrapper function that does the right On Tue, Jul 15, 2014 at 11:18 PM, klutzy notifications@github.com wrote:
|
|
Here's quick-and-dirty hack. I'm sure cross build unwinding is broken, but anyway |
|
For 64-bit target (x86_64-w64-mingw32), Debian and Ubuntu switched to seh. However, for 32-bit target, Debian, Ubuntu, Arch use sjlj. Since sjlj is considered as "slow-but-reliable" default and dwarf is "fast-but-unreliable" option, many linux distros has provided sjlj only. (it's not mingw-w64 specific; old mingw has suffered same issue. Debian issue) |
|
I wonder, is this still true today? |
|
I think it's still true on 32-bit since the core issue is just that most distribution uses "common" unwinding (sjij) different to what we want (dwarf). (It's not a problem for 64-bit.) |
|
I'm still not sure what's the best action to close this. The "complete" fix is just to build cross gcc from scratch. The simplest fix is "let's add fake sjij-unwinding support". We could add more proper sjlj support on Windows, but I'm not sure how meaningful it is. |
|
@klutzy, what makes it "fake"? But yeah, the bigger question is: Do we have a compelling reason for supporting SjLj in addition to Dwarf on win32? |
|
Does that mean the Windows MinGW builds use different configuration than the Linux cross-compilers for the same target? |
|
MinGW is available in both flavors, but we only support the dwarf one. |
In particular, specify the target triple when specifying the name of the linker executable. This makes it possible to cross compile to Windows: rustc --target=x86_64-pc-windows-gnu without having to pass rustc the "-C linker=" parameter. This fixes cross compilation to 64-bit Windows. However, due to unwinding issues (rust-lang#12859) this does not fix cross compilation to 32-bit Windows. Additionally, update make-win-dist.py. This allows (non-cross) compilation on Windows to continue to work.
Just curious, what would it take to add SjLj support? a LOT of work? |
|
Hi, I was wondering if there was an update on this issue. Ideally, I'd like to not rebuild gcc from scratch. I'm interested in rust to be used with mruby and particularly with setting up a cross compiling toolchain from linux -> 32/64 bit osx and winodws. I believe I've run into the same issue with trying to build target |
|
Compatibility with Windows mingw builds and bitrot aside, the main sticking point, as I recall, was figuring out which mingw flavor we have during the compilation of some std::rt modules. |
|
I'm going to close this as basically "there's nothing we can do here". Cross compiling works for x86_64 where we don't depend on the style of unwinding of the MinGW toolchain, but we can only cross compiling to a MinGW toolchain targeting dwarf exceptions on 32-bit. Unfortunately the toolchains on Linux tend to be SjLj based, but that's just not the binaries we ship for libstd. |
|
@alexcrichton, so what happened to the SEH plan from #30448? Is it not possible for the 32-bit gnu target after all? |
|
Unfortunately there's a combination of:
(1) may be surmountable but I couldn't make heads or tails of (2) unfortunately :( |
|
Hi, i'm new to rust, and with what I understood of this thread (not that much), I fixed it adding the option |
|
I don't think I've ever seen a distribution-shipped version of MinGW that was configured to not use SJLJ exception handling for 32-bit. In fact, it is so rare, I wasn't even aware it existed as an upstream-supported option. If you are going to hard-code a specific variant, you should hard-code SJLJ for 32-bit, or Rust essentially becomes arbitrarily incompatible with the entire rest of the MinGW ecosystem. Like, this is six years after this bug was filed, and I can report that everyone is still using SJLJ, AFAIK no one is talking about changing that, and Rust thereby still fails to compile 32-bit binaries for Windows. :( |
|
@saurik Fedora ships Dwarf-2 i686 MinGW toolchain, basically all popular native Windows MinGW toolchains also default to Dwarf-2. |
|
@mati865 Ok, you know what? I'm sorry. FWIW, both Ubuntu and macOS Homebrew are shipping SJLJ, which is why I'm still experiencing this bubble of SJLJ whenever I do any tests, as those are the operating systems I normally work with; it turns out you are right: the packages on repo.msys2.org, which is what I'd consider the official decision at this point, are using Dwarf-2. …and what's weird is that my own projects are also using Dwarf-2, and I simply didn't notice, as I'm actually using clang to do my Win32 compilation right now, and it is, in fact, generating Dwarf-2. This is where I was just really dumb: I put the math together all wrong here and came to the wrong conclusions about what toolchains were doing what. While "basically all popular" still doesn't seem quite right (and you actually said the opposite multiple times in #49078... ;P), it certainly is morally correct, so again: I'm sorry. The issue I'm experiencing is really then just an issue overriding the sysroot of the linker, and I'll take the comments over to #68887, I guess :(. |
I might have not been clear enough. I wanted to say "toolchains running on the Windows natively", Linux distros indeed mostly ship SJLJ based toolchain for i686. This issue is far beyond #68887. It'd require adding rustc argument to switch between DWARF-2 and SJLJ, then you'd have to use build-std, xargo or cargo-xbuild to build std library with chosen exception handling. Another solution would be adding new i686 target triple which would use only SJLJ. |
|
For a project of mine I hit this error. I can't belive this issue dates from 2014 RLY? https://gist.github.com/zzeroo/2f4168364eda226c7ec808a9153ad472 I try to set up a cross compilation environment to compile win32 binaries from a linux box. For separation I use docker containers, sorry that's all I can do to simplify the problem. Please see: https://gitlab.com/zzeroo/rust-crosspile the Dockerfile describes my setup: https://gitlab.com/zzeroo/rust-crosspile/-/blob/master/Dockerfile This are the steps to get to the error git clone https://gitlab.com/zzeroo/rust-crosspile -b i686
cd rust-crosspile
docker build . -t rust-crosspile
cd /tmp
cargo build --bin hello-world
cd example
docker create -v `pwd`:/home/rust/src --name HELLO-build rust-crosspile:latest
docker start -ai HELLO-build |
|
@zzeroo it's your distribution issue. |
|
@mati865 thank you for this fast help. Sorry for that stupid question. |
|
I am hitting this issue when trying to cross-compile from linux to 32-bit windows - on Debian, the 32-bit mingw still uses sjlj. @mati865 if I patch |
|
Never mind, I found this PR and comment which explains why my intended approach would not be feasible (and it's also not as simple as setting that flag). |
Unfortunately this triggers rust-lang/rust#12859
…d-all-the-time-please, r=Veykril feat: don't highlight the whole fn on return-type mismatch
… r=Alexendoo [`many_single_char_names`]: Deduplicate diagnostics Relates to rust-lang#12379 Fix `many_single_char_names` lint so that it doesn't emit diagnostics when the current level of the scope doesn't contain any single character name. ```rust let (a, b, c, d): (i32, i32, i32, i32); match 1 { 1 => (), e => {}, } ``` produced the exact same MANY_SINGLE_CHAR_NAMES diagnostic at each of the Arm `e => {}` and the Block `{}`. --- changelog: [`many_single_char_names`]: Fix duplicate diagnostics
(See later posts,
_Unwind_Resumesymbol is missing)The text was updated successfully, but these errors were encountered: