Windows: Inconsistent import lib naming

[xclaesse]

Usually libraries and their import lib on Windows are named following those conventions:

• MSVC has foo.dll and foo.lib
• GCC has libfoo.dll and libfoo.dll.a

However:

• With rustc and GCC linker (e.g. when cross compiling for Windows) I'm expecting to be following GCC convention, and do rustc ... -o libfoo.dll to get libfoo.dll and libfoo.dll.a but instead of produces liblibfoo.dll.a (notice the repetition of the prefix).
• With rustc and MSVC linker I'm expecting that rustc ... -o foo.dll would produce foo.dll and foo.lib but instead of produces foo.dll.lib.

Is that inconsistency intentional? Especially the lib prefix repetition in the import lib is problematic, that means we can't really build libfoo.dll without having an import library with a bad naming. Unless there is something I missed?

[xclaesse]

Forgot to mention, this is when creating a cdylib. Maybe there is an equivalent to -Wl,--out-implib,libfoo.dll.a to override the default?

[ChrisDenton]

IIRC, in the MSVC case, the use of foo.dll.lib is to help avoid conflict with a static foo.lib you may also produce.

[xclaesse]

@ChrisDenton that would make sense, yes. I think the biggest issue here is rustc prefix the import lib with lib, which means if I want libfoo.dll like gcc would do, it produces liblibfoo.dll.a instead of libfoo.dll.a. Unless there is a trick I'm not aware of?

[xclaesse]

CC @matthiaskrgr who seems to have worked in this area according to git blame. I don't understand what the code does, but I would imagine it's something there: https://github.com/rust-lang/rust/blob/master/compiler/rustc_codegen_llvm/src/back/archive.rs#L152.

[amyspark]

Just ran into this when testing GStreamer's Rust bindings, Meson is generating static libraries with .a by default, but rustc enforces .lib. So all static libraries built by Meson for MSVC will result in not found errors when used from the Rust side.

I did find the corresponding entry in the target settings, but I'm not sure if it's possible to override it, or how rustc is figuring the import libraries out to begin with:

rust/compiler/rustc_target/src/spec/windows_msvc_base.rs

Line 15 in 2ceed0b

staticlib_suffix: ".lib".into(),

[xclaesse]

CC @matthiaskrgr who seems to have worked in this area according to git blame. I don't understand what the code does, but I would imagine it's something there: https://github.com/rust-lang/rust/blob/master/compiler/rustc_codegen_llvm/src/back/archive.rs#L152.

I believe the relevant code is there: https://github.com/rust-lang/rust/blob/master/compiler/rustc_codegen_ssa/src/back/linker.rs#L346. I imagine that file is "libfoo.dll" and it prepend/append staticlib prefix/suffix which result into duplicated "lib" prefix.

CC @petrochenkov who touched that code according to git blame.

[xclaesse]

I have basically no idea what I'm doing, not even sure how to compile rustc to test, but I think this is the fix:

diff --git a/compiler/rustc_codegen_ssa/src/back/linker.rs b/compiler/rustc_codegen_ssa/src/back/linker.rs
index 11afe0fbc3c..f9b63c840f1 100644
--- a/compiler/rustc_codegen_ssa/src/back/linker.rs
+++ b/compiler/rustc_codegen_ssa/src/back/linker.rs
@@ -342,8 +342,7 @@ fn build_dylib(&mut self, out_filename: &Path) {
                 let implib_name =
                     out_filename.file_name().and_then(|file| file.to_str()).map(|file| {
                         format!(
-                            "{}{}{}",
-                            self.sess.target.staticlib_prefix,
+                            "{}{}",
                             file,
                             self.sess.target.staticlib_suffix
                         )

[xclaesse]

IIRC, in the MSVC case, the use of foo.dll.lib is to help avoid conflict with a static foo.lib you may also produce.

For that reason Meson decided to name static libraries libfoo.a on all platforms. See https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa.

There are also discussion about this in Meson: mesonbuild/meson#8153.