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.
> 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.)
>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.
Reading through the status tracking bug, it sounds like the ABI is now standardised, but they aren't changing the default to the newly standard ABI yet, because they are waiting on external tools to support it. That said, you could definitely use it today without worrying about the compiler version it seems.
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.