JEjeffdavis·Apr 23, 2020
I feel like I've been pushing my use case plenty already, so please take this as an answer to your question rather than one more push ;-)
I'd like to be able to create plugin-style cdylibs that get loaded into a host program. For instance, PostgreSQL extensions are shared libraries (typically written in C) that need to be loaded into a running instance of postgres for integration testing. I am trying to make it reasonable to write such extensions in rust (https://github.com/jeff-davis/postgres-extension.rs).
The environment variable to find the shared library would solve one problem, but there are still a couple more right behind it:
* Running "cargo test" tries to build a binary that links to the library to run the unit tests, but this will fail because there are unresolved symbols in the .so file (symbols that call APIs in the host prog
Read the rest
ram, in this case PostgreSQL functions like palloc()). In other words, the test binary is useless because it can't load the plugin.
* Linux seems fine creating a .so with unresolved symbols, but Mac and Windows need special linker flags. I can document that the linker flags are needed by consumers of my crate, but it would be nice if there was a better/supported way to create plugin-style shared libraries. I tried filing a bug with PR (https://github.com/rust-lang/rust/pull/66204) it was determined that it needed to go through the RFC process.
The simplest way to see the problem is to look at this crate: https://github.com/jeff-davis/unresolved
My problems don't end there, unfortunately. For my crate to really work, I also need to solve the problem of setjmp/longjmp at the edges between C and Rust (https://github.com/rust-lang/rfcs/issues/2625).