Broken nightly toolchain for windows-gnu since 2018-03-17

[rkarp]

This is the last working version:

$ rustup toolchain install nightly-2018-03-16-gnu
info: syncing channel updates for 'nightly-2018-03-16-x86_64-pc-windows-gnu'
info: latest update on 2018-03-16, rust version 1.26.0-nightly (392645394 2018-03-15)
info: downloading component 'rustc'
info: downloading component 'rust-std'
info: downloading component 'cargo'
info: downloading component 'rust-docs'
info: downloading component 'rust-mingw'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'cargo'
info: installing component 'rust-docs'
info: installing component 'rust-mingw'

  nightly-2018-03-16-x86_64-pc-windows-gnu installed - rustc 1.26.0-nightly (392645394 2018-03-15)

For nightly-2018-03-17 rustc doesn't work at all:

$ rustup toolchain install nightly-2018-03-17-gnu
info: syncing channel updates for 'nightly-2018-03-17-x86_64-pc-windows-gnu'
info: latest update on 2018-03-17, rust version 1.26.0-nightly (55c984ee5 2018-03-16)
info: downloading component 'rustc'
info: downloading component 'rust-std'
info: downloading component 'cargo'
info: downloading component 'rust-docs'
info: downloading component 'rust-mingw'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'cargo'
info: installing component 'rust-docs'
info: installing component 'rust-mingw'

  nightly-2018-03-17-x86_64-pc-windows-gnu installed - (error reading rustc version)

When trying to run rustc from that nightly, there's an error about not being able to find an entry point for CreateMutexA in api-ms-core-synch-l1-2-0.dll. This is on 2 different computers running Windows 7 Pro x64.

[leonardo-m]

For me the last working Nightly version is:

rustc 1.26.0-nightly (9c9424de5 2018-03-27)
binary: rustc
commit-hash: 9c9424de51da41fd3d1077ac7810276f8dc746fa
commit-date: 2018-03-27
host: x86_64-pc-windows-gnu
release: 1.26.0-nightly
LLVM version: 6.0

[rkarp]

The problem seems to be that rustc-errors.dll has gained a dependency on api-ms-core-synch-l1-2-0.dll. On nightly-2018-03-16 CreateMutexA is instead imported from kernel32.dll.

[retep998]

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 synchronization.lib/libsynchronization.a through winapi recently. Fixing it would require either reverting that dependency change or doing some complicated shenanigans involving import libraries and winapi.

This error seems stopped with version 1.26.0-nightly (517f24025 2018-03-31) on my Windows 7 Pro x64,

Does anyone know what commit fixed it?

I'm not able to locate it at Commits merged on Mar 31, 2018 at Master.

rustup install nightly-2018-03-16-gnu
info: syncing channel updates for 'nightly-2018-03-16-x86_64-pc-windows-gnu'
info: latest update on 2018-03-16, rust version 1.26.0-nightly (392645394 2018-03-15)
[...]

** Ok **

rustup install nightly-2018-03-17-gnu
info: syncing channel updates for 'nightly-2018-03-17-x86_64-pc-windows-gnu'
info: latest update on 2018-03-17, rust version 1.26.0-nightly (55c984ee5 2018-03-16)
[...]

** Error **  rustc.exe : 
 The procedure entry point CreateMutexA could not be located 
 in the dynamic library api-ms-win-core-synch-l1-2-0.dll

[...]

rustup install nightly-2018-03-31-gnu
info: syncing channel updates for 'nightly-2018-03-31-x86_64-pc-windows-gnu'
info: latest update on 2018-03-31, rust version 1.26.0-nightly (80785a547 2018-03-30)
[...]

** Error **  rustc.exe : 
 The procedure entry point CreateMutexA could not be located 
 in the dynamic library api-ms-win-core-synch-l1-2-0.dll

rustup install nightly-2018-04-01-gnu
info: syncing channel updates for 'nightly-2018-04-01-x86_64-pc-windows-gnu'
info: latest update on 2018-04-01, rust version 1.26.0-nightly (517f24025 2018-03-31)
[...]

** Ok **

rustup install nightly
info: syncing channel updates for 'nightly-x86_64-pc-windows-gnu'
info: latest update on 2018-04-02, rust version 1.26.0-nightly (06fa27d7c 2018-04-01)
[...]

** Ok **

[rkarp]

It's not yet fixed for me on version 1.27.0-nightly (056f589fb 2018-04-07).

Idem

rustup install nightly-2018-04-04-gnu
info: syncing channel updates for 'nightly-2018-04-04-x86_64-pc-windows-gnu'
info: latest update on 2018-04-04, rust version 1.27.0-nightly (637ac17c5 2018-04-03)

** Error **  rustc.exe : 
 The procedure entry point CreateMutexA could not be located 
 in the dynamic library api-ms-win-core-synch-l1-2-0.dll

 [...]

rustup install nightly-2018-04-08-gnu
info: syncing channel updates for 'nightly-2018-04-08-x86_64-pc-windows-gnu'
info: latest update on 2018-04-08, rust version 1.27.0-nightly (056f589fb 2018-04-07)

** Error **  rustc.exe : 
 The procedure entry point CreateMutexA could not be located 
 in the dynamic library api-ms-win-core-synch-l1-2-0.dll

[pnkfelix]

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 ?

[retep998]

After further investigation I have found that MinGW's libsynchronization.a is actually quite different from MSVC's synchronization.lib.

synchronization.lib has just these symbols:

WaitOnAddress
WakeByAddressAll
WakeByAddressSingle

libsynchronization.a meanwhile has all of these symbols:

AcquireSRWLockExclusive
AcquireSRWLockShared
CreateEventA
CreateEventExA
CreateEventExW
CreateEventW
CreateMutexA
CreateMutexExA
CreateMutexExW
CreateMutexW
CreateSemaphoreExW
DeleteCriticalSection
EnterCriticalSection
InitOnceBeginInitialize
InitOnceComplete
InitOnceExecuteOnce
InitOnceInitialize
InitializeConditionVariable
InitializeCriticalSection
InitializeCriticalSectionAndSpinCount
InitializeCriticalSectionEx
InitializeSRWLock
LeaveCriticalSection
OpenEventA
OpenEventW
OpenMutexW
OpenSemaphoreW
ReleaseMutex
ReleaseSRWLockExclusive
ReleaseSRWLockShared
ReleaseSemaphore
ResetEvent
SetCriticalSectionSpinCount
SetEvent
Sleep
SleepConditionVariableCS
SleepConditionVariableSRW
SleepEx
TryAcquireSRWLockExclusive
TryAcquireSRWLockShared
TryEnterCriticalSection
WaitForMultipleObjectsEx
WaitForSingleObject
WaitForSingleObjectEx
WaitOnAddress
WakeAllConditionVariable
WakeByAddressAll
WakeByAddressSingle
WakeConditionVariable

These exports lead to DLLs that only exist on newer versions of Windows, and are overriding the exports from libkernel32.a. Therefore this is entirely MinGW's fault for providing such shoddy import libraries that don't match their msvc equivalents. Also do note that this issue does not manifest when using winapi normally, only when building Rust because Rust does not use winapi's bundled import libraries. So as far as I can see there are a few ways we can deal with this.

1. Get rid of or modify whatever dependency is enabling the synchapi feature of winapi which causes libsynchronization.a to be linked in.
2. Get this fixed upstream in MinGW.
3. Replace libsynchronization.a from MinGW with our own version (borrow the one from winapi perhaps).
4. Somehow figure out how to use winapi's bundled import libraries. Would be a lot easier if Rust wasn't a massive pile of dylibs to support plugins.

As a workaround for users in the meantime, the -msvc toolchain still works fine on Windows 7 and you can cross to -gnu if you really need to work with MinGW.

[bricky149]

This issue now affects the beta channel after 1.26 beta 9 got the dodgy commit. MSVC works fine on Windows 7 x64.