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).

[MartinKolbAtWork]

I am facing exactly this issue when trying to use Rust-based libraries (i.e. I used the two Rust-based WebAssembly engines Wasmtime and Wasmer) in a C/C++ code-base.

These Rust libraries have no SONAMES, which causes the CMake build to produce wrong binaries.

I opened an issue at CMake, but these folks clearly confirmed that shared libraries without an SONAME entry are a bug that needs to be fixed by the one building the library:
https://gitlab.kitware.com/cmake/cmake/-/issues/22307#note_971562

Could you please continue working on this topic? Otherwise consuming Rust-based libraries with the popular CMake build system will remain awkward.

[lu-zero]

Ideally you might get around setting the CARGO to cargo capi if cargo-ndk calls normally cargo build cargo install or extend a little cargo-ndk to know about cargo-c and call it instead of cargo if present.

For android you shouldn't have problems not using cargo-c for it.

[weihanglo]

Out of curious. What's the missing part to make progress on this issue?

From my understanding, rustc-link-arg family in build script solve this issue somehow. We could also simply run something like the following to build a shared library with SONAME:

cargo rustc --crate-type cdylib -- -C link-arg=-Wl,-soname,libmycrate.so

Sorry I am a bit lost on this thread…

[jschwe]

What's the missing part to make progress on this issue?

For me, it's this part from the opening post (emphasis mine):

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.

So what's missing from my point of view is a decision if cargo could automatically set the soname for cdylibs according to semver, or at least provide an opt-in mechanism for this, which is a bit more user-friendly than setting linker flags.

[phi-gamma]

Another argument for having Cargo set the DT_SONAME: Only Cargo knows
it is linking the final binary and not some dependency. Here’s an
example where the build.rs approach fails: https://gitlab.com/phgsng/buggy-soname
I also outlined the problem on discourse: https://users.rust-lang.org/t/89245

The gist of it is that one library that is built as a cdylib
depends on another which also produces a cdylib. This causes the
build.rs of both libraries to be executed and Cargo ends up
appending the two extra link-args but in the wrong order, so the
wrong SONAME ends up in the shared object. Ideally, Cargo would add
the correct SONAME argument to the linker line exactly once, when
linking the final shared object.

(This is not a contrived usecase but based on a real world product that
is unfortunately proprietary.)

[weihanglo]

See also

• DyLib does not store the version information in the generated binary #2273