0

When creating a wrapper around a (C) library libfoo that is either itself commonly dynamically linked or links some dependencies dynamically, should the crate libfoo-sys include this library and its dependencies in some way? If so, how?

In case libfoo-sys should not include the library, how should the crate ensure a sufficiently compatible version is present on the system? The most pragmatic thing I can think of is for the build of dependents to fail if the relevant libfoo version is missing. An alternative would be to try to install the relevant version with common package managers instead but I'd be worried to break a crate-user's environment in that way.

I looked at some examples of wrapper crates and couldn't find any indication of them including the base library which seems odd to me. Searching for the question didn't yield any definitive answer.

Edit: I am most interested in the case of libfoo not supporting static linking at all, or very badly.

Jan Hettenkofer
  • 139
  • 4
  • 13
  • You might want to see how [the `openssl` crate does it](https://docs.rs/openssl/latest/openssl/). They have a `vendored` feature to statically link the library from source (with the `openssl-src` crate), but by default dynamically link the system library. – PitaJ Dec 06 '22 at 17:32
  • Thanks for the pointer to openssl. I like the option to fall back to static linking, but what if static linking is not supported or actively discouraged by the original library? I clarified the question about this. – Jan Hettenkofer Dec 06 '22 at 17:38
  • 1
    I certainly wouldn't attempt to install the library automatically. Just throw a compilation error if the library can't be found, and tell the user to install it. – PitaJ Dec 06 '22 at 17:40

0 Answers0