[ivmoreau]

> Too bad rust doesn't really do dynamic linking.

As far as I remember, you can actually do dynamic linking. But it has its caveats.

Maybe using two different crates, lib-internal and lib-external, where lib-internal compiles to an dylib/so that exposes a C-abi compatible interface. Lib-external it’s just a idiomatic Rust wrapper to that api. It’s a little bit wonky, but I’m pretty sure that it can work.

[zozbot234]

> It’s a little bit wonky, but I’m pretty sure that it can work.

Not that wonky, it's really a natural consequence of the fact that Rust's stable ABI is the C ABI. Plus you can then use lib-internal from any language that supports FFI to C, not just from Rust.

(Of course, some things just cannot be supported across a dylib boundary, such as arbitrary monomorphized code. But this limitation applies to all such languages; it's why you have "header-only" libraries in C/C++ for example.)

[pabs3]

Apparently there is a dynamic linking ABI for Rust too, but it is not stable enough to use yet for distros like Debian.

https://wiki.debian.org/StaticLinking#Rust https://lwn.net/Articles/797616/ https://github.com/rust-lang/rfcs/pull/2603

I note that the PR for Rust symbol mangling got merged, but it looks like it isn't the default yet, they are waiting on external tools supporting it.

[ivmoreau]

>but it is not stable enough That's the problem. Is still, after all this years, unstable.

Of course you can do dynamic linking without the way that I previously described, but that library will be highly tight to a specific version of the compiler. I think that the biggest problem is dealing with product types for that matter.