Support loading a build.rs compiled .so with -Zmiri-native-lib

[Nemo157]

It's common for projects to build C dependencies in the build-scripts of -sys dependencies. To be able to use these along with miri's new FFI support requires some weird contortions:

> cargo miri test
...
error: unsupported operation: can't call foreign function ...
> MIRIFLAGS=-Zmiri-native-lib=target/shared/miri/x86_64-unknown-linux-gnu/debug/build/foobar-sys-fb396848c056a26f/out/libfoobar.so cargo miri test

(along with making the build script detect CARGO_CFG_MIRI and switch to outputting a shared object instead of the normal staticlib).

It'd be nice if there were some way to inform miri about the native lib from the build script, similar to how we can tell the linker about the native libraries (maybe there's some way miri could reuse these cargo commands?).

cargo:rustc-link-lib=static=foobar
cargo:rustc-link-search=native=$OUT_DIR

[RalfJung]

Yeah, so far we haven't thought at all about automation or integration here, just about the basic infrastructure. These are some good starting points, thanks!

I do think we still want to require some explicit opt-in in MIRIFLAGS though. Miri has to behave a bit differently in native-libs mode, there is the risk of missing UB, the C code could mess up Miri's internal state entirely -- this is not something we should just do silently.

[Nemo157]

Maybe it could be supported by parsing the rustc-link-search flags, but not the link-lib ones, so the end-user still needs to list the libraries to load, but doesn't have to find the correct out-paths

MIRIFLAGS=-Zmiri-native-lib=libfoobar.so cargo miri test

I don't actually know, does miri have any kind of search path for the libraries right now?

[RalfJung]

We just call libloading::Library::new(lib_file_path). I have no idea if that has a search path.

[bjorn3]

I have no idea if that has a search path.

That follows the runtime dylib search path (LD_LIBRARY_PATH on most Unixes, DYLD_LIBRARY_PATH on macOS and PATH on Windows) At least on the systems I tried, the dynamic linker will respect those env vars even if you set them at runtime right before loading a dynamic library rather than before starting the program.