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.