Prefer-dynamic=yes in hot-reload or plugin system

[c00t]

Recently, I wanted to implement an experimental plugin system in my application. After reading Mario's article, I understood that I need to ensure that all types appearing in the plugin interface are FFI-safe.

Next, I read the section on hot reloading in the fyrox book, which requires the following command to compile the plugin:

RUSTFLAGS="-C prefer-dynamic=yes" cargo build --package game_dylib --no-default-features --features="dylib-engine" --profile dev-hot-reload

The book states:

This command will compile the engine DLL (fyrox_dylib.dll/so ) and the plugin DLL (game_dylib.dll/so ). Please note the mandatory environment variable RUSTFLAGS="-C prefer-dynamic=yes" . It forces the compiler to link standard library dynamically. It is very important, because if not set, the standard library will be duplicated in game plugin and engine, which will lead to subtle bugs.

Hmm... I understand that this may be related to static variables in the standard library (including thread_local variables), such as Thread::name(). But isn't dynamically linking to std-xxxxxx.dll relying on a very fragile fact? That is, the ABI stability under the same version of the compiler.

Considering that I might be the only one developing plugin, can I rely on the ABI stability by fixing compiler version in both the plugin and runtime? That is, I can freely pass types like String, Vec, etc. in the plugin interface.

Or should I follow the approach in Mario's article, keeping it FFI-safe while statically linking to the standard library?

[bjorn3]

@c00t

That is, the ABI stability under the same version of the compiler.

ABI stability with the exact same version of libstd on the same compiler version is effectively guaranteed. I don't know of any way this can be violated. For different libstd/compiler versions, the dynamic linker will give an error that it can't find required functions as each rustc version mangles symbol names differently, thus saving you from UB there too.