Dynamic linking is quite possible. You have to use the C ABI however when interfacing with code that's not part of the build.

We do this _all the time_ as we write almost all of our software in Rust, but lots of it is for use with/in embedded systems developed in C.

It's true that you can mate up to C by exporting the C ABI everywhere. This isn't a free lunch though. There are annoying and/or weird side-effects you sometimes have to deal with when leaning heavily into doing this.

> This isn't a free lunch though. There are annoying and/or weird side-effects you sometimes have to deal with when leaning heavily into doing this.

as a person not super-experienced in rust, im curious what kind of side-effects? binary size bloat?

That works in theory but often not in practice. The problem is that many C libraries keep their API backwards compatible but not their ABI. For example, a function might become a macro or the size of a struct might change.

It is possible to keep the ABI backwards compatible by practicing good C hygiene, but many library authors doesn't know how. Especially when it comes to Windows which is a platform most C library authors are not intimately familiar with.

Dynamic linking requires a backwards-compatible ABI essentially by definition. If the ABI changes, that involves a bumped SONAME and version number hence binary objects should never end up being linked in incompatible ways.

Few library authors understand that. In recent years libmq, libpcre, and libssh have all introduced ABI breaking changes without bumping the SONAME. Unless you have very detailed knowledge of how dynamic linking works on all supported platforms it is very hard to know what constitutes an ABI break.

The reason it mostly works on Linux is because header files are available. For example, if a function in library A that program B depends on is changed to a macro then all that is required is for B to be recompiled. Which B almost always is because most users get their software from package archives that are recompiled when dependencies are updated.

On Windows there is no such thing as an SONAME and Microsoft has essentially given up on ABI compatibility. If you write C or C++ in Visual Studio you must ship with it with the language runtime dlls for that version of Visual Studio. Microsoft doesn't guarantee ABI compatibility with any other version of the runtime.

It looks like the Windows equivalent is called a "Side by side manifest". It has to be opted-in-to from both the shared object (.DLL for Windows) side and the loading application, though. On Linux, it just works - it is idiomatic to include major version in SONAME.

libc usually does pretty well, FWIW.