Windows: Static libraries should end with .a not .lib when using MinGW/GCC #43749
Description
It looks like there might be a regression on Windows, where Rust static libraries built with/for MinGW have the MSVC naming, instead of GCC naming. So the shared library has a .lib suffix, and isn't prepended with 'lib'. This seems to be the reverse of issue #29508.
My pared down test case was the rust-ffi-examples code, which because of this is currently broken for an MSYS2 setup (I hope I have done something wrong):
$ rustup show Default host: i686-pc-windows-gnu installed toolchains -------------------- stable-i686-pc-windows-gnu nightly-i686-pc-windows-gnu (default) active toolchain ---------------- nightly-i686-pc-windows-gnu (default) rustc 1.21.0-nightly (dd53dd5f9 2017-08-01) user@DESKTOP-LL841I9 MINGW32 ~/rust-ffi-examples/c-to-rust $ make cargo build Compiling c-to-rust v0.1.0 (file:///C:/msys32/home/zeno/rust-ffi-examples/c-to-rust) note: link against the following native artifacts when linking against this static library note: the order and any duplication can be significant on some platforms, and so may need to be preserved note: library: advapi32 note: library: ws2_32 note: library: userenv note: library: shell32 note: library: gcc_eh note: library: pthread Finished dev [unoptimized + debuginfo] target(s) in 1.7 secs cc -o target/double target/main.o target/debug/libdouble_input.a -lws2_32 -luserenv cc.exe: error: target/debug/libdouble_input.a: No such file or directory make: *** [Makefile:14: target/double] Error 1 user@DESKTOP-LL841I9 MINGW32 ~/rust-ffi-examples/c-to-rust $ ls target/debug build deps double_input.d double_input.lib examples incremental native