Add implib to the stamp files #6875
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
rust-highfive
added
the
S-waiting-on-review
|
I'm not familiar with gnu linking on Windows. Whenever I try to build a dylib with |
|
I think we'll probably want to hold off merging this until rust-lang/rust#60260 reaches a conclusion as well, but we can of course test it in the meantime :) I'm gonna try to comment more on rust-lang/rust#60260 today |
|
Do you have the exact error and/or linker line? I'd bet on a missing crtbegin.o/crtend.o You might also have to ensure the linker is actually the mingw-w64 one, I've had cases where the linker was a native gcc, which didn't work so well (but I'll confess I haven't look into this at all) |
|
I'm using the regular mingw from mingw.org. I'm a little confused by mingw-w64, is that yet another clone? I find the whole mingw/msys stuff somewhat confusing. Searching for
Here's the link output:
|
|
I agree that it easily confusing. TL;DR: mingw is the original windows toolchain to cross compile from linux to windows |
|
Arg sorry, posted too early. I have no experience with mingw, and have only used/contributed to mingw-w64. From a quick look I don't see any reference to onexitbegin/onexitend in either gcc/llvm not mingw-w64 so I wonder it it's not a mingw (non -w64) specificity. |
This was already done when targetting msvc, but it needs to be done for all targets to allow rustc to link with shared libraries when using llvm -l<dllname> is only supported by gcc, while llvm needs an import library to link indirectly with a dll
|
@chouquette to double-check, is this still necessary for the UWP targets? |
|
@alexcrichton it's not UWP specific but LLD specific (using @ehuss it's known Rust bug: rust-lang/rust#47048 the best workaround known to me is replacing problematic libraries like here: https://github.com/rust-lang/libc/pull/1376/files#diff-479f71e48abedfd84790e1287381eb8dR49 |
|
@ehuss your issue is mostly fixed on nightly. Could you test it again? |
| @@ -213,6 +213,17 @@ impl TargetInfo { | |||
| should_replace_hyphens: false, | |||
| }) | |||
| } | |||
| else if target_triple.ends_with("windows-gnu") | |||
There was a problem hiding this comment.
| else if target_triple.ends_with("windows-gnu") | |
| // LD can link DLL directly but LLD requires import library | |
| if target_triple.ends_with("windows-gnu") |
|
I'm sorry for the long delay. This change seems reasonable to me. @alexcrichton Would it be OK to add a x86_64-pc-windows-gnu job to Cargo's CI? I'd like to test this, and in general I think it would be good to have some test coverage for windows-gnu. |
|
Yeah I'd be fine adding that, it's been tricky historically but it's probably much easier now! |
|
I'll see if I can make tests pass. Due to recent changes to MinGW targets I suppose the tests will yield different results for stable, beta and nightly. |
|
@mati865 That would be great if you can help. Would you be up for opening a PR? I started, but I only got as far as: diff --git a/azure-pipelines.yml b/azure-pipelines.yml
index 392ecb9ed..fdd3141b5 100644
--- a/azure-pipelines.yml
+++ b/azure-pipelines.yml
@@ -41,6 +41,9 @@ jobs:
x86_64-msvc:
TOOLCHAIN: stable-x86_64-pc-windows-msvc
OTHER_TARGET: i686-pc-windows-msvc
+ x86_64-gnu:
+ TOOLCHAIN: nightly-x86_64-pc-windows-gnu
+ OTHER_TARGET: i686-pc-windows-gnu
- job: rustfmt
pool:
diff --git a/ci/azure-install-rust.yml b/ci/azure-install-rust.yml
index f37b4a6ab..f11171506 100644
--- a/ci/azure-install-rust.yml
+++ b/ci/azure-install-rust.yml
@@ -4,7 +4,7 @@ steps:
rustup set profile minimal
rustup component remove --toolchain=$TOOLCHAIN rust-docs || echo "already removed"
rustup update --no-self-update $TOOLCHAIN
- if [ "$TOOLCHAIN" = "nightly" ]; then
+ if [[ "$TOOLCHAIN" == "nightly"* ]]; then
rustup component add --toolchain=$TOOLCHAIN rustc-dev
fi
rustup default $TOOLCHAINI think using nightly would be good just to mix things up (since we don't have any windows nightly tests). The tests that failed were: The |
|
@ehuss I'm waiting on my Azure Pipelines before opening WIP PR.
|
Add windows-gnu CI and fix tests
One remaining failure:
```
---- features::feature_off_dylib stdout ----
running `d:\a\1\s\target\debug\cargo.exe build --features f1`
running `d:\a\1\s\target\debug\cargo.exe run -p bar`
thread 'features::feature_off_dylib' panicked at '
Expected: execs
but: exited with exit code: 101
--- stdout
--- stderr
Compiling foo v0.0.1 (D:\a\1\s\target\cit\t663\foo)
Compiling bar v0.0.1 (D:\a\1\s\target\cit\t663\foo\bar)
Finished dev [unoptimized + debuginfo] target(s) in 0.69s
Running `target\debug\bar.exe`
thread 'main' panicked at 'assertion failed: `(left == right)`
left: `"f1"`,
right: `"no f1"`', bar\src\main.rs:5:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\bar.exe` (exit code: 101)
', crates\cargo-test-support\src\lib.rs:833:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
features::feature_off_dylib
```
I disassembled the dylibs and `cargo run -p bar` correctly rebuilt it inside `target/debug/deps/` but did not copy it to `target/debug`. To further confirm, calling `cp target/debug/deps/foo.dll target/debug/` manually solved the issue.
Any idea?
----
I left `FIXME` in places where import lib should be added with #6875.
`TOOLCHAIN: nightly-x86_64-pc-windows-gnu` can be replaced with beta on Thursday.
Uplift windows gnu DLL import libraries. This is a repost of #6875, rebased with tests fixed.
|
I have rebased this and fixed the tests in #8141. |
Hi,
This MR aims at including the import libraries in the stamp file, in order for them to be copied around when uplifting stages during rust-lang's compilation.
This was already done when targetting msvc, but it needs to be done for
all targets to allow rustc to link with shared libraries when using llvm.
-l is only supported by gcc, while llvm needs an import library
to link indirectly with a dll
This MR is related to rust-lang/rust#60260
I'm unsure what the best way is, when it comes to cross dependent MRs, so I'll gladly change things according to your reviews!
Thanks,