-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add windows-gnu CI and fix tests #8139
Conversation
r? @Eh2406 (rust_highfive has picked a reviewer for you, use r? to override) |
r? @ehuss |
Hm, so there's more detail in #6167 where that test was introduced. Dependency DLL's are not copied into I'm a bit confused why the gnu toolchain has a different search order. I tried to find something useful in https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order, but that only confused me more. It says "The directory from which the application loaded." is first, so I would assume that test should fail with MSVC (we launch the executable in So, anyways, I'm guessing something in the GNU setup is changing the search order to include the binary's directory before One possibility is to go with option 3 described at #6162 (comment), where all dependency DLLs should be copied to "Uplifting" is done here. The outputs of each unit are computed in |
azure-pipelines.yml
Outdated
# FIXME: switch to stable when 1.44 is released | ||
TOOLCHAIN: nightly-x86_64-pc-windows-gnu |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to keep this on nightly permanently, so that we have some nightly testing for Windows (which enables a bunch of tests that are usually ignored).
MinGW and MSVC both use the same library loader from the OS. Somehow MSVC creates hardlinks but MinGW copies
EDIT: |
Ah, good observation. My guess would be a difference in linker behavior. In the presence of an existing file, MSVC probably truncates and modifies, preserving the hardlink, whereas gnu probably replaces the file, breaking the hardlink (at least, that's my guess). Awesome, thanks for helping! |
@bors r+ |
📌 Commit 2dd0b0d has been approved by |
I had tested LLD before and it failed the same way with gnu target. Lld-link with msvc target had no errors. |
☀️ Test successful - checks-azure |
Update cargo, rls ## cargo 17 commits in ebda5065ee8a1e46801380abcbac21a25bc7e755..8751eb3010d4cdb5329b5a6bd2b6d765c95b0dca 2020-04-16 14:28:43 +0000 to 2020-04-21 18:04:35 +0000 - Uplift windows gnu DLL import libraries. (rust-lang/cargo#8141) - Add windows-gnu CI and fix tests (rust-lang/cargo#8139) - Several updates to token/index handling. (rust-lang/cargo#7973) - Add `resolver` opt-in for new feature resolver. (rust-lang/cargo#8129) - Improve error message when running `cargo install .` (rust-lang/cargo#8137) - fix mem replace unused (rust-lang/cargo#8138) - Change `-Cembed-bitcode=no` use to `-Cbitcode-in-rlib=no`. (rust-lang/cargo#8134) - Refactor BuildContext (rust-lang/cargo#8068) - Rename allows_underscores to allows_dashes. (rust-lang/cargo#8135) - Fixed a needless borrow. (rust-lang/cargo#8130) - Add link to changelog in the Cargo book. (rust-lang/cargo#8126) - Fix target for doc test cross compilation (rust-lang/cargo#8094) - Add note about .cargo/config support. (rust-lang/cargo#8125) - Fix pdb uplift when executable has dashes. (rust-lang/cargo#8123) - Hint upgrading for future edition keys (rust-lang/cargo#8122) - Use some fs shorthand functions. (rust-lang/cargo#8124) - Update documentation to mention "config.toml" instead of "config" (rust-lang/cargo#8121) ## rls 1 commits in 2659cbf14bfb0929a16d7ce9b6858d0bb286ede7..7de2a1f299f8744ffe109139f9f1fdf28bfec909 2020-04-14 22:07:24 +0200 to 2020-04-19 22:41:55 +0000 - Update cargo (rust-lang/rls#1663)
One remaining failure:
I disassembled the dylibs and
cargo run -p bar
correctly rebuilt it insidetarget/debug/deps/
but did not copy it totarget/debug
. To further confirm, callingcp 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.