I'm trying to build a sys crate that provides bindings to a proprietary(-ish) SDK. I (and anyone else) can easily download the C header files and .so, and I'm even allowed to distribute the .so. I want dependents (also me) of this sys crate to be able to easily ship their executable along with the same version of the so as the sys crate ran bindgen against.
The solutions I've come up with are all bad in different ways:
I make the final executable download the SDK and provide environment variables to the sys-crate build script so it knows where it is. However, I've got no way of enforcing that it's the right version in this case.
The sys crate downloads (or ships) the right shared object, however this ends up in the OUT_DIR of the sys crate somewhere in target and isn't accessible to anyone but cargo (because there might be old ones lying around).
Cargo doesn’t support shared libraries well enough to put them in the right location relative to the binary or update their rpath. It only does bare minimum for system-wide libraries installed at a well-known location.
Without a global absolute path location it’s typical that either cargo run or cargo test stops working, or the release binary stops working when it’s outside of the target/ dir.
Cargo also has no post-build scripts that could properly bundle an .so with an executable.
You could provide an installer that will install the .so system-wide. For users that want to bundle it with an executable you can provide a script that fixes the binaries after the build and puts a copy of .so alongside them.
That's very sad, thanks though. The problem with the installer idea is that it's hard to validate that the versions of the sys library and the installed SDK match, which makes me nervous.