Broken nightly toolchain for windows-gnu since 2018-03-17 #49438
Comments
|
For me the last working Nightly version is: |
|
The problem seems to be that |
kennytm
added
regression-from-stable-to-nightly
|
Ah the joys of relying on import libraries from MinGW and hoping everything resolves where we want it... This was likely caused by something depending on |
|
This error seems stopped with version Does anyone know what commit fixed it? I'm not able to locate it at Commits merged on |
|
It's not yet fixed for me on |
|
Idem |
|
Is one of the participants here interested in attempting to bisect down to a particular commit (rather than just a date) via https://github.com/rust-lang-nursery/cargo-bisect-rustc ? |
nikomatsakis
added
the
T-compiler
|
After further investigation I have found that MinGW's
These exports lead to DLLs that only exist on newer versions of Windows, and are overriding the exports from
As a workaround for users in the meantime, the |
|
This issue now affects the beta channel after 1.26 beta 9 got the dodgy commit. MSVC works fine on Windows 7 x64. |
retep998
added
regression-from-stable-to-beta
|
@retep007 which of those options do you think would be the best choice? Maybe we should file an issue with MinGW just to get their opinion? I guess my preference, in order, would be to (a) file an issue, then (b) remove the dependency if we can, else (c) use an alternate version of the library. |
|
cc @rust-lang/infra -- using an alternate version of the library seems more to fall in your domain =) at least, I don't really know what's involved |
nikomatsakis
added
T-infra
pietroalbini
removed
the
T-compiler
|
@rkarp and @leonardo-m, is this still happening for you on nightly? Looking at the dependencies on today's nightly it looks like the DLL dependency has disappeared so I'd just want to confirm that works so we can figure out what to backport. |
|
I also can't see the dependency in beta.12 (today's beta release). Was this perhaps accidentally fixed? Could y'all who have been reproducing this confirm whether ornot it's been fixed? |
|
The difference between beta.9 and beta.12 doesn't really show much why this would be fixed one way or the other... |
|
https://github.com/retep998/winapi-rs/blob/c54b3e8d887644316654f8fb4ab8dd2aabad70bd/build.rs#L388 The order in which winapi emits libraries is random so it occurs in some versions but not others, which means reproducing is like rolling a die. Whether |
|
@retep998 can the nondeterminism be fixed? Sounds like it's at least problematic here! |
Unfortunately the `parking_lot` crate enables the `synchapi` feature of the `winapi` crate which activates a dependency on `libsynchronization.a`. The MinGW version of `libsynchronization.a` pulls in a dependency `api-ms-core-synch-l1-2-0.dll` which causes rustc to not work on Windows 7 (tracked in rust-lang#49438) The `parking_lot` crate is not currently used in the compiler unless parallel queries are enabled. This feature is not enabled by default and not used at all in the beta/stable compilers. As a result the dependency in this commit was removed and the CI build which checks parallel queries was disabled. This isn't a great long-term solution but should hopefully be enough of a patch for beta to buy us some more time to figure this out.
|
I've excised the dependency which enables @Zoxc do you have thoughts on this? The |
|
And to be clear #50254 is intended to be a beta-only fix, a fix is still needed for master. |
[beta] Remove dependency on `parking_lot` Unfortunately the `parking_lot` crate enables the `synchapi` feature of the `winapi` crate which activates a dependency on `libsynchronization.a`. The MinGW version of `libsynchronization.a` pulls in a dependency `api-ms-core-synch-l1-2-0.dll` which causes rustc to not work on Windows 7 (tracked in #49438) The `parking_lot` crate is not currently used in the compiler unless parallel queries are enabled. This feature is not enabled by default and not used at all in the beta/stable compilers. As a result the dependency in this commit was removed and the CI build which checks parallel queries was disabled. This isn't a great long-term solution but should hopefully be enough of a patch for beta to buy us some more time to figure this out.
|
We could just remove the dependency on |
|
@Zoxc would you be willing to look into removing |
|
The nondeterministic ordering of libraries is never an issue when winapi is used normally, because normally none of the libraries import the same symbol from two different dlls. It's only because of the unique way that rustbuild builds winapi (by relying on an external MinGW toolchain instead of bundled import libraries) which causes this issue to be possible. Besides, it's not like the random order causes the issue, it merely makes the issue nondeterministic and therefore slightly harder to debug. There are functions in the |
|
@retep998 we like to keep the builds of rustc as deterministic as possible. Ordering not only affects the final artifact but interediate rlibs. Would you accept a PR to make the ordering deterministic? |
|
@retep998 this also seems like it's buggy on behalf of winapi? The documentation indicates that |
Pulling in `parking_lot` to the Rust compiler unfortunately had adverse side effects on the binary dependencies of rustc -- rust-lang/rust#49438. It turns out this is due to a number of bugs happening all at once, and currently we're looking for ways to fix the beta/master branches of rustc to fix this for now (not necessarily in the best way). This commit removes the activation of the `synchapi` feature of `winapi` which prevents `libsynchronization.a` from being linked in (and prevents rustc from accidentally picking up a dependency on a missing DLL). The `synchapi` feature was only activated for access to the `Sleep` function, but that function actually resides in `kernel32.dll`. As a result this commit inlines the definition of `Sleep` into this crate to avoid needing to depend on an upstream definition.
|
@alexcrichton If you enable the In this specific case however, Rust is choosing to use import libraries from MinGW instead of using winapi's bundled import libraries and the I will make the ordering deterministic though, but that won't solve the underlying problem of MinGW's |
Pulling in `parking_lot` to the Rust compiler unfortunately had adverse side effects on the binary dependencies of rustc -- rust-lang/rust#49438. It turns out this is due to a number of bugs happening all at once, and currently we're looking for ways to fix the beta/master branches of rustc to fix this for now (not necessarily in the best way). This commit removes the activation of the `synchapi` feature of `winapi` which prevents `libsynchronization.a` from being linked in (and prevents rustc from accidentally picking up a dependency on a missing DLL). The `synchapi` feature was only activated for access to the `Sleep` function, but that function actually resides in `kernel32.dll`. As a result this commit inlines the definition of `Sleep` into this crate to avoid needing to depend on an upstream definition.
|
Switching the regression tag to nightly as this should be fixed on beta now. @retep998 there's a whole mess of bugs here, and I'm looking for any route to fix it. Sounds like it's not the easiest to fix in winapi, so we won't rely on fixing it there then. |
alexcrichton
added
regression-from-stable-to-nightly
This commit updates `parking_lot` to pull in Amanieu/parking_lot#70 and... Closes rust-lang#49438
…Mark-Simulacrum Update `parking_lot` dependencies This commit updates `parking_lot` to pull in Amanieu/parking_lot#70 and... Closes rust-lang#49438
This is the last working version:
For nightly-2018-03-17 rustc doesn't work at all:
When trying to run rustc from that nightly, there's an error about not being able to find an entry point for
CreateMutexAinapi-ms-core-synch-l1-2-0.dll. This is on 2 different computers running Windows 7 Pro x64.The text was updated successfully, but these errors were encountered: