Inconsistent library name creation over operating system

[Lecrapouille]

Problem

I've never developed with Rust, but I'm facing issue with the creation of the library name made by someone else.

Cargo.toml:

[lib]
name = "libstigmark_client"
crate-type = [
    "dylib",        # .dll, .so, .dynlib
    "staticlib"     # .lib, .a
]

Will create in target/debug/ a libstigmark_client.lib for Windows but a liblibstigmark_client.a (same for dynamic lib). So liblib :)

[lib]
name = "stigmark_client"
crate-type = [
   "dylib",        # .dll, .so, .dynlib
   "staticlib"     # .lib, .a
]

Will create stigmark_client.lib for Windows but libstigmark_client.a (same for dynamic lib).

The issue is that when linking with the Python Makefile named Scons it will add -l so the 2nd method is good for Linux but for Windows the 1st method is the good one.

Steps

1. Standard compilation

Possible Solution(s)

When parsing the library name:

[lib]
name = "libxxx"

• if libxxx is matched do not add extra lib
• if xxx is matched then add libxxx

Notes

No response

Version

cargo 1.58.0 (7f08ace4f 2021-11-24)
release: 1.58.0
commit-hash: 7f08ace4f1305de7f3b1b0e2f765911957226bd4
commit-date: 2021-11-24
host: x86_64-unknown-linux-gnu
libgit2: 1.3.0 (sys:0.13.23 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1l)
os: Debian 11 (bullseye) [64-bit]

[weihanglo]

Thanks for the report! The output filenames are not controlled by cargo but rustc. For staticlib on windows-msvc toolchain, the output static lib is deliberately shipped as foo.lib without lib prefix. IMO the solution you proposed is unlikely to implement because it will be a breaking change. You can consult the default target options and any other target you're interested in under this directory.

Anyway, thanks for your findings!

Refs:

• Initial MSVC support for the compiler rust#25350
• https://doc.rust-lang.org/1.58.1/reference/linkage.html
• https://github.com/rust-lang/rust/blob/1.58.1/compiler/rustc_target/src/spec/mod.rs#L1422-L1529
• https://github.com/rust-lang/rust/blob/1.58.1/compiler/rustc_target/src/spec/windows_msvc_base.rs

[ehuss]

I'm going to close as this is expected behavior when working on the msvc target. Libraries on msvc don't use the lib prefix, and it is normal to pass the library name like foo.lib to cl.exe or link.exe. I'm not sure what problem you are running into with scons, as I'm not too familiar with it.

[KiARC]

I am having actual failing builds trying to build a library and bin from the same project for both Windows and Linux since the PDB's collide. There's no way this is a weird edge case. I agree that changing the behavior of rustc would be bad, but there needs to be documentation and a fix available. On that note, how might I explicitly tell cargo what I want the libraries to be named?

[weihanglo]

Not sure if I understand correctly, but you could name each target explicitly via the name field.

[Lecrapouille]

I reply since I did not explain why this behaviour bothered me: I used Scons for building application and one lib was made in Rust. Scons, whatever for Linux or Window, when it sees xxx it will expand to libxxx. In my case, it was not a big issue, since I renamed xxx to libxxx for Windows. In a general way, I hate the implicit 'lib' prefix whatever Scons, Rust, Linux tools because that creates so many issues just for saving 3 chars 1 char (libxxx vs. -lxxx).