x86_64-pc-windows-gnu: ld: cannot find -lcredui and -lsecur32 after upgrading to rustc 1.26.0-nightly (521d91c6b 2018-03-14)

[messense]

https://ci.appveyor.com/project/laumann/compiletest-rs/build/1.0.38/job/o8rkn779qh7ios49

error: linking with gcc failed: exit code: 1 | = note: "gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-m64" "C:\Users\appveyor\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib\dllcrt2.o" "C:\Users\appveyor\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib\rsbegin.o" "-L" "C:\Users\appveyor\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.serde_derive0.rcgu.o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.serde_derive1.rcgu.o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.serde_derive10.rcgu.o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.serde_derive11.rcgu.o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.serde_derive12.rcgu.o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.serde_derive13.rcgu.o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.serde_derive14.rcgu.o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.serde_derive15.rcgu.o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.serde_derive2.rcgu.o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.serde_derive3.rcgu.o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.serde_derive4.rcgu.o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.serde_derive5.rcgu.o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.serde_derive6.rcgu.o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.serde_derive7.rcgu.o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.serde_derive8.rcgu.o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.serde_derive9.rcgu.o" "-o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.dll" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.crate.metadata.rcgu.o" "C:\projects\compiletest-rs\target\debug\deps\serde_derive-9ebadb45ca9eec02.crate.allocator.rcgu.o" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "C:\projects\compiletest-rs\target\debug\deps" "-L" "C:\Users\appveyor\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib" "-Wl,-Bstatic" "C:\projects\compiletest-rs\target\debug\deps\libserde_derive_internals-555f0e717120011b.rlib" "C:\projects\compiletest-rs\target\debug\deps\libsyn-9d73a1b0d8b88639.rlib" "C:\projects\compiletest-rs\target\debug\deps\libquote-cce34627b501f031.rlib" "C:\projects\compiletest-rs\target\debug\deps\libproc_macro2-73d79182fd654d90.rlib" "C:\projects\compiletest-rs\target\debug\deps\libunicode_xid-25214f6da763bedd.rlib" "-L" "C:\Users\appveyor\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib" "-Wl,-Bdynamic" "-l" "proc_macro-93dbabd980fbabf9" "-L" "C:\Users\appveyor\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib" "-l" "syntax-031c8126770b77bb" "-L" "C:\Users\appveyor\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib" "-l" "rustc_errors-f2eda81f3e9dcbb7" "-L" "C:\Users\appveyor\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib" "-l" "syntax_pos-f46872503870f814" "-L" "C:\Users\appveyor\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib" "-l" "rustc_data_structures-c0d56ce5645d455f" "-L" "C:\Users\appveyor\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib" "-l" "serialize-60f2dac169f8734f" "-L" "C:\Users\appveyor\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib" "-l" "rustc_cratesio_shim-ce4463286aac2a73" "-L" "C:\Users\appveyor\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib" "-l" "std-6b18c18bbc608054" "-Wl,-Bstatic" "C:\Users\appveyor\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib\libcompiler_builtins-362c10b9d34fdd8e.rlib" "-Wl,-Bdynamic" "-l" "kernel32" "-l" "credui" "-l" "setupapi" "-l" "user32" "-l" "secur32" "-l" "advapi32" "-l" "winspool" "-l" "msimg32" "-l" "gdi32" "-l" "opengl32" "-l" "kernel32" "-l" "dbghelp" "-l" "advapi32" "-l" "ws2_32" "-l" "userenv" "-l" "shell32" "-shared" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-lmsvcrt" "-luser32" "-lkernel32" "C:\Users\appveyor\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib\rsend.o" = note: ld: cannot find -lcredui ld: cannot find -lsecur32

error: aborting due to previous error error: Could not compile serde_derive.

It builds fine with nightly-2018-03-07

https://ci.appveyor.com/project/laumann/compiletest-rs/build/1.0.38/job/rcfcfv3mfmx7h6t3

The relevant code here: https://github.com/laumann/compiletest-rs/pull/108

[nikomatsakis]

@messense can you narrow down the date range when it broke any further (e.g., try 2018-03-08)? That would help a lot in figuring out what changed. (Or is that the next nightly after 2018-03-08...?)

[nikomatsakis]

triage: P-high

[messense]

There are no nightly releases between 2018-03-08 and 2018-03-14 I think?

[nikomatsakis]

@messense I see, shame.

I'm going to assign this to myself, but I'll have to figure out some way to reproduce first. If you're willing, it may be possible to use the per-PR bors builds to bisect this down, but I'm not sure if those are available for x86_64-pc-windows-gnu (cc @rust-lang/release)

[nikomatsakis]

@messense This tool can install our intermediate builds, which are available for every PR that lands:

https://crates.io/crates/rustup-toolchain-install-master

@kennytm thinks it works on windows, but has never tried it. Think you could try to use it? To start, you might try 2789b067da2ac921b86199bde21dd231ace1da39, which is the commit that 2018-03-07 builds and hence which ought to work.

You would do something like:

> rustup-toolchain-install-master 2789b067da2ac921b86199bde21dd231ace1da39
> cargo +2789b067d build

[messense]

@nikomatsakis I don't have any Windows machine/VM so I'll have to use AppVeyor to try it.

https://ci.appveyor.com/project/laumann/compiletest-rs/build/1.0.39

[nagisa]

So, this is amusing. The dependency on these libraries is pulled in -- and, I think, provided -- by winapi that is linked to by libstd, but we neglect to ship the files!

cc @alexcrichton was there a winapi upgrade past few days? cc @retep998 does this theory appear correct to you?

[nagisa]

No such dependency was present in the 03-07 version.

[messense]

Oh no, rustup-toolchain-install-master does not build.

error: failed to run custom build command for lzma-sys v0.1.9 process didn't exit successfully: C:\Users\appveyor\AppData\Local\Temp\1\cargo-install.awHWa8SE4m3J\release\build\lzma-sys-41f0afb77098a370\build-script-build (exit code: 101) --- stdout cargo:rerun-if-env-changed=LZMA_API_STATIC cargo:rustc-link-search=C:\Users\appveyor\AppData\Local\Temp\1\cargo-install.awHWa8SE4m3J\release\build\lzma-sys-19ff7df3ceadee56\out/lib cargo:root=C:\Users\appveyor\AppData\Local\Temp\1\cargo-install.awHWa8SE4m3J\release\build\lzma-sys-19ff7df3ceadee56\out cargo:include=C:\Users\appveyor\AppData\Local\Temp\1\cargo-install.awHWa8SE4m3J\release\build\lzma-sys-19ff7df3ceadee56\out/include cargo:rerun-if-changed=xz-5.2.3/configure cargo:rustc-link-lib=static=lzma OPT_LEVEL = Some("3") TARGET = Some("x86_64-pc-windows-gnu") HOST = Some("x86_64-pc-windows-gnu") TARGET = Some("x86_64-pc-windows-gnu") TARGET = Some("x86_64-pc-windows-gnu") HOST = Some("x86_64-pc-windows-gnu") CC_x86_64-pc-windows-gnu = None CC_x86_64_pc_windows_gnu = None HOST_CC = None CC = None TARGET = Some("x86_64-pc-windows-gnu") HOST = Some("x86_64-pc-windows-gnu") CFLAGS_x86_64-pc-windows-gnu = None CFLAGS_x86_64_pc_windows_gnu = None HOST_CFLAGS = None CFLAGS = None DEBUG = Some("false") running: "sh" "/C/Users/appveyor/AppData/Local/Temp/1/cargo-install.awHWa8SE4m3J/release/build/lzma-sys-19ff7df3ceadee56/out/src/configure" "--prefix=/C/Users/appveyor/AppData/Local/Temp/1/cargo-install.awHWa8SE4m3J/release/build/lzma-sys-19ff7df3ceadee56/out" "--disable-doc" "--disable-lzma-links" "--disable-lzmainfo" "--disable-lzmadec" "--disable-xz" "--disable-xzdec" "--disable-scripts" "--disable-shared" "--disable-nls" "--disable-rpath" "--enable-threads=win95" XZ Utils 5.2.3 System type: checking build system type... x86_64-pc-msys checking host system type... x86_64-pc-msys Configure options: checking if debugging code should be compiled... no checking which encoders to build... lzma1 lzma2 delta x86 powerpc ia64 arm armthumb sparc checking which decoders to build... lzma1 lzma2 delta x86 powerpc ia64 arm armthumb sparc checking which match finders to build... hc3 hc4 bt2 bt3 bt4 checking which integrity checks to build... crc32 crc64 sha256 checking if external SHA-256 should be used... no checking if assembler optimizations should be used... x86_64 checking if small size is preferred over speed... no checking if threading support is wanted... yes, win95 checking how much RAM to assume if the real amount is unknown... 128 MiB checking if library symbol versioning should be used... no checking if sandboxing should be used... no checking for a shell that conforms to POSIX... /bin/sh Initializing Automake: checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... no checking whether make supports nested variables... no checking whether ln -s works... no, using cp -pR checking for style of include used by make... none checking for gcc... gcc.exe checking whether the C compiler works... no --- stderr configure: error: in /tmp/cargo-install.awHWa8SE4m3J/release/build/lzma-sys-19ff7df3ceadee56/out/build': configure: error: C compiler cannot create executables Seeconfig.log' for more details thread 'main' panicked at 'assertion failed: try_run(cmd)', C:\Users\appveyor.cargo\registry\src\github.com-1ecc6299db9ec823\lzma-sys-0.1.9\build.rs:182:5 note: Run with RUST_BACKTRACE=1 for a backtrace.

[retep998]

For Rust builds winapi is configured to depend on import libraries bundled with Rust (or provided by an external MinGW) instead of the prefixed import libraries it bundles itself when used normally. If Rust ends up enabling a certain feature of winapi but forgets to also bundle the corresponding import library, then you get this sort of error. libstd does not depend on winapi so this issue only manifests when someone builds a compiler plugin that depends on internal Rust crates because those do depend on winapi.

The fix is simple, make sure you always keep the MinGW import libraries bundled with Rust in sync with what winapi has been asked to link to. If only someone could write a test to ensure this doesn't fall out of sync...

[messense]

@kennytm It seems that rustup-toolchain-install-master does not download cargo, thus

cargo +2789b067da2ac921b86199bde21dd231ace1da39 build error: toolchain '2789b067da2ac921b86199bde21dd231ace1da39' does not have the binary cargo.exe

[nikomatsakis]

@retep998

Thanks!

The fix is simple, make sure you always keep the MinGW import libraries bundled with Rust in sync with what winapi has been asked to link to.

Is there a list somewhere of what we bundle? How is that controlled? (Do you know?)

If only someone could write a test to ensure this doesn't fall out of sync...

Is there some reason we can't?

[retep998]

Is there a list somewhere of what we bundle? How is that controlled? (Do you know?

Where the list of bundled libraries is currently set: https://github.com/rust-lang/rust/blob/6c70cd149d3d5e568fc35cb58e4df728e14a567b/src/bootstrap/dist.rs#L201-L229

https://github.com/rust-lang/rust/issues/47359 keeps track of which bundled import libraries we currently need.

Is there some reason we can't?

It's entirely possible to write such a test. It's just that nobody has done so due to being a bit tricky.

[nagisa]

It ought to be possible to run run-pass-fulldep test suite in an environment that hasn’t the full mingw. This would prevent the tests from picking up dependencies from the CI’s mingw.

[kennytm]

@messense Thanks, strange that it requires a cargo.exe on Windows. Could you retry after installing a nightly toolchain?

Although for this, it is better to use https://github.com/Mark-Simulacrum/bisect-rust to automatically find the regression commit.

[alexcrichton]

I've opened a PR at https://github.com/rust-lang/rust/pull/49055 to extend the list we're shipping.

[NovemberZulu]

If you have MSYS installed, then there is an ugly workaround: copy libcredui.a and libsecur32.a from /mingw64/x86_64-w64-mingw32/lib to .multirust\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib . It worked for me when I tried to install clippy, but then I got hit by rust-lang-nursery/rust-clippy#2532 :(

[NovemberZulu]

When is it going to land in nightly? Right now -- rustc 1.26.0-nightly (55c984ee5 2018-03-16) -- I have three(!) library missing when building clippy 0.0.188:

  = note: ld: cannot find -lsynchronization
          ld: cannot find -lcredui
          ld: cannot find -lsecur32

[petrochenkov]

See https://github.com/rust-lang/rust/issues/49080 for more info on -lsynchronization. It's possible that we need to ship it as a part of our distribution as well.

[kennytm]

@NovemberZulu nightlies are released at 00:00 UTC, so should be in 2-3 hours.

[NovemberZulu]

UPDATE: Never mind, I got totally confused without git gui