Allow configuring name of generated shared library artifact

[xmo-odoo]

Currently a library named foo will generate an artifact libfoo.dylib on OSX. That's probably the right default, but it's doubly problematic when building CPython libraries (native modules):

• CPython's import statement will lookup the shared library's name exactly (ignoring extension) requiring an import libfoo. The lib prefix is very rarely used in Python (the lib suffix somewhat more so, libfoo might also be the postfix to a Python binding to libfoo e.g. python-libfoo). This is compounded by "accelerator" native modules (as replacements or improvements of pure-python ones) normally being prefixed by _: Cargo would generate lib_foo rather than the expecting _foo
• CPython doesn't look for .dylib files, it apparently only looks for .so files, even in OSX

Being able to provide an exact name for generated library artifacts (maybe platform-wise?) would fix both issues.

I didn't find any way to achieve that via a build script, or the native parameters of cargo build.

[thirtythreeforty]

You would need a pair of new options to fix this cleanly, I think.

The reason is that I can specify several types of libraries to build:

[lib]
name = "foo"
crate-type = ["dylib", "rlib"]

Cargo will build both a libfoo.so and a libfoo.rlib (on Linux; I'm not familiar with OS X). So you would need a way to both specify the name's prefix and set the suffixes for the various library types:

[lib]
name = "foo"
libprefix = ""
libsuffix = {dylib = "so"}
crate-type = ["dylib", "rlib"]

This example would emit foo.so and foo.rlib.

This would allow you to override specific parts of the name for some types of outputs, while leaving sensible and platform-independent defaults for everything else.

Alternately, you could do both in one setting:

[lib]
name = "foo"
crate-type = ["dylib", "rlib"]
exactname = {dylib = "{}.so", rlib = "{}.rlib"}

(And the {} would be replaced with the name.) But I like this idea less.

[xmo-odoo]

Cargo will build both a libfoo.so and a libfoo.rlib (on Linux; I'm not familiar with OS X).

The same on OSX, except the first one is called libfoo.dylib

[alexcrichton]

Would it be possible to just rename the artifact? Cargo's not necessarily striving to be the end-all-be-all of Rust build systems, and it's pretty likely you'll need scripting of some form layered on top of Cargo for integration into projects like this. Along those lines I'd expect a CPython library to run cargo build to generate libfoo.dylib and then afterwards it'd rename the file to whatever it needed.

[virtualritz]

+1.
For people building dynamic libraries that are loaded as plug-ins to other apps (at runtime) this is a commonly required feature as these rarely follow naming conventions of the platform. They often use UpperCamelCase for the name and have extensions like .plugin or no extension at all.

Currently this requires using something likecargo post or, worse, some other build tool like CMake for something that could be trivially added.

I second @thirtythreeforty suggestions for new options.

[ianks]

This is a critical feature IMO. I’m trying to build an easy way to build native Rust extension is ruby and ruby wants .bundle as the dylib name on Mac.

[benkay86]

This feature would also be useful for writing Matlab extension, which end in something like *.mexa64 instead of *.so. I'm kind of surprised there's not already some way to do this, even with build.rs, but having support in cargo would be fantastic.

[weihanglo]

Some other possible solution:

• Not elegant workaround: cargo rustc --lib -- --emit link="mydylib.whatever".
• There is an unstable feature different-binary-name (tracking issue Tracking Issue for different-binary-name #9778) enabling Cargo to set a different file name for [[bin]] targets. Supporting [lib] is also in the discussion.
• Post build script could also help with this (Post-build script execution #545).

[StripedMonkey]

I am currently working on writing a pam module, and would like the library artifact to match the naming scheme of other pam modules using pam_programname.so. This is currently impossible, as the artifact gets named libpam_programname.so

Obviously renaming is an option, but why is there an assumption in the first place that shared libraries must always have the lib prefix? This is something I'm not clear on at all.
It seems mildly obtuse that a "convenience" feature, like prepending library names with lib, should overtake the more obvious and (imho) reasonable option of simply name =ing it libxxx if that is actually needed for the project's build artifacts. Roping in an external build tool for the singular act of renaming a single build artifact seems needlessly over complicating the build process for... a reason I can't quite figure out.

[alshdavid]

Yes, I have a workspace with a library and an executible entry point that acts as a frontend for that library

[workspace]

members = [
  "foo",
  "libfoo",
]

Running cargo build --release however produces a library called target/release/liblibfoo (.dll/.so/.dylib).

It would be nice if Cargo could emit the file with the name exactly as described