Publishing a sys wrapper to a closed source library

We are working with a closed source C/C++ api (we only have headers and lib files). We can use bindgen to generate bindings the use a build script to copy the lib files in the OUT directory so it will link properly.

On top of the sys crate we have built a safe abstraction and derive-like crate.

So far cargo refuses to publish (says it cannot verify package tarball). I would like to know if there is way to publish this kind of crates ?

PS: From my understanding the vendor allows to distribute the libs with a permissive license (there are many python packages available for instance).

1 Like

My understanding of the publish process:

  • cargo packages up all files into a .crate file, excluding things in .gitignore and as marked in Cargo.toml
  • cargo creates a temporary directory to test the crate
  • cargo unpacks that packaged file into the temp directory
  • cargo builds the packaged file
  • if successful, cargo publishes to crates.io

You seem to be failing on the fourth step, where it's trying to build in a temp directory. While you could avoid this step, I think it is a real problem. When anyone depends on the crate, the crate will be built in $CARGO_HOME/src/github-xxx/crate-name_crate-version/, and you definitely don't want to require users to stick a lib file in that source directory.

If your crate can't even build in a temporary directory on your computer, how is it supposed to build from inside $CARGO_HOME?


What you want to do is fine, though. It should be exactly the same as a crate like rust-openssl, which depends on OpenSSL being installed separately to build. (it does have a vendored flag to allow for building openssl itself, but by default depends on an external library to exist).

To fix this, maybe you could adopt a strategy for locating the library more like the one OpenSSL uses? As long as it searches somewhere in system files, independent of your repo's folder, it should work.

Since your library is publicly available, is there an installer for it? If so, maybe you could look into where it sticks the lib files, and search independently?

Or if you're already doing that, then look into why it's failing. Maybe try cloning a fresh git repository, and building that? That should show you the same errors that cargo is getting. Something's failing because it can't work without ignored files in the project repo, so making a fresh clone in a different directory should give you an opportunity to debug those errors.

4 Likes

Thank you for your answer!

I've successfully published my crate. For the moment (0.0.1 version) I will require users to set a XXX_LIB environment variable.

I may try to enhance it later with pkg-config (simplified version of what has been done in open-ssl) but it'll be good enough for now.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.