Cargo: Support soname for cdylibs

[kornelski]

rustc supports setting soname via -C link-arg. However, it can't be used from Cargo, since RUSTFLAGS affects all invocations of the compiler, and it could potentially set soname on dependencies.

Some previous discussions about soname support were dismissed based on the fact that Rust's native ABI is not stable. That is not relevant for cdylibs, because the C ABI exposed by cdylibs is stable.

I'm interested in using this feature in cargo-deb. soname is required to build first-class Linux libraries (e.g. for Debian) with Rust.

I think it'd be wonderful if Cargo automatically set soname of cdylib to semver-major when version is >= 1.0.0 (i.e. don't set any for 0.x.x), since soname and semver-major promise basically the same thing. However, a separate Cargo.toml field, command line flag, or env var would work as well.

[gibix]

I'm interested for the same reason of @kornelski to be able to cross-compile rust libs on gentoo.

[kornelski]

The lack of support for linker flags is one of issues preventing librsvg from switching to Cargo. It needs flags like this:

    -version-info @RSVG_LT_VERSION_INFO@ \
    -export-dynamic \
    -no-undefined \
    -export-symbols-regex "^rsvg_.*" 

[sdroege]

Those are all libtool flags and not direct linker flags that ld or link.exe would handle.

[kornelski]

Ah, ok. Still needs a post build script or something, since the vanilla cdylib crate type doesn't have it.

[lu-zero]

@kornelski I'm updating my patch, then we can work on the installing phase together if you like :)

I need it already for crav1e and the relibc developer seem interested as well.

[federicomenaquintero]

From #6298, am I correct in understanding that the remaining work is to figure out platform-specific linker arguments to define the soname and such?

[lu-zero]

The install phase rfc and this have more details on what is missing.

I might take this weekend to publish my draft applet so we can experiment a bit outside cargo if you want to join me in this :)

[kornelski]

But this is about cargo build, not cargo install, so the RFC won't help.

For example, cargo-deb needs to be able to build a correct library, without installing it system-wide. Running cargo install as part of package creation would be a very undesirable "leakage" that could pollute the build machine.

[lu-zero]

What I'm preparing is something along the lines of:

cargo c install --prefix=/usr --destdir=/staging/place

No pollution at all :)

[kornelski]

But isn't that a workaround? It reminds me of ugly hacks like make install. The products are already in target/, they're just built wrong. I don't want to install anything, to any location, I just want to finish building them.

[lu-zero]

It is not.
If you want to build only you just issue a build command.

As a packager I enjoy having a working install target that gets all I need in the right places without having to reinvent the wheel every time. Nobody is forcing you to use what I'm writing :)

[kornelski]

Oh, you mean you're writing "cargo-c"? I assumed that c was a typo, and you were suggesting cargo install as the workaround (and that RFC goes way beyond staging build products, into making cargo install a package manger that can't uninstall what it has installed, so I'm very dismayed by it).

[lu-zero]

yes, I try to make an applet to generate all that's needed (.pc files, .h files, etc) and install it without to have to repeat myself too much (currently we are having a small vlc workshop so I might or might not get to publish it this weekend)

[lu-zero]

Now I have two ways to help on this:

• https://crates.io/crates/cdylib-link-lines if you want just to use build.rs and just build the .so
• https://github.com/lu-zero/cargo-c if you want to build and install a C-lib-like package.

Ideally I could make a separate crate for the .pc creation as well if somebody needs it.

[h0ru5]

new to rust/cargo: would there be a possibility to write a plugin that does set the soname as post-production step? (yes, it is a workaround until mainline can do it).

Right now I try to do the same on the side consuming the .so

[lu-zero]

it is, you may using cdylib-link-lines (even if it could enjoy an overhaul).