ELF soname is missing

[m4b]

So I'm seeing several issues obliquely referencing unstable ABIs, soname's, and dynamically linked libraries, but it's not really clear at all to me:

1. why rust doesn't set the soname for an ELF binary
2. why this isn't documented why rust doesn't set the soname for an ELF binary

In several of these threads the point is made that rust doesn't need to set the soname because rust's ABI is unstable. Unless I'm misunderstanding something, this argument isn't valid.

Unless I'm deeply mistaken, rust has (or had better) have a stable C ABI. I can expose unmangled symbols which have a C calling convention.

Hence I can distribute a dynamically linked library (DSO) with, for example, the following C API:

void * abi_create();
void abi_mutate(void*);

If Rust's C ABI/FFI implementation is stable (i.e., doesn't have major bugs, etc.) (and I should hope so), then this will never change from an external consumer viewpoint (unless I change the unmangled function definitions).

Now, if Rust's internal ABI for regular rust functions changes from compiler to compiler is irrelevant, assuming the semantics of the rust code is the same, as the C ABI acts as a stable portal into the binary.

Hence from an external consumer, the binary's ABI is stable, unless of course I change the C function names/api/semantics, then this is the same old problem from 1903 about what to do when C binaries change their function's semantics problem (in which case, whatever guidelines your distro has in place, or what have you, for DSO versioning should be adhered to, which is typically many guidelines, none of which are ever obeyed ;)

Consequently, not setting the soname on the grounds that rust's internal ABI is unstable is not valid.

A tertiary concern here is that Rust will seem much much more mature in my opinion if we start dotting our I's and crossing our T's w.r.t. this kind of stuff, as it will make, for example, a Rust-based system DSO much more appealing from a distro standpoint if the binaries artifacts we produce are in tip top condition, imho.

[cuviper]

From the perspective of something like the dynamic loader (ld.so), there's no difference between C/FFI functions that could maintain a stable ABI, versus pure Rust functions which definitely do not. They're all just symbols in a table, to be matched against the requirements of whatever loads the library.

Now, it should be possible to have a Rust cdylib which exports a stable C ABI, and for that you probably do want to set the soname. But even then, I don't think this is something rustc should set automatically. Maintaining portable ABI is a choice - advisable but not assumed.

Even when you do want the soname set, its actual value is a choice too, which may not have any relation at all to the raw version of your library. For instance, libc-2.24.so has soname libc.so.6, set in stone quite a while ago even as the library continues to evolve.

When you do want it, you can probably use something like -C link-arg=-Wl,-soname,libfoo.so.42.

[Mark-Simulacrum]

Judging by what @cuviper says, it seems that we don't want to set the soname by default (and as far as I know, we don't today); Since -C link-arg is stable and this is a rather obscure feature, I'm going to close. If you're interested in changes in this area, please do let us know and we'll reopen.