Closed AxelNennker closed 5 years ago
Maybe libsodium-sys set something rusty like cargo:rustc-link-search=native={}
What would be the advantage of telling zeromq-src where the lib is vs. building directly from source?
For instance we could build and link against libsodium-sys directly.
I imagine something in zeromq-src like
I think something like this might work
sodiumoxide = "0.2.2"
Or similar that tells this crate the if the feature 'libsodium' is requested this crate depends on sodiumoxide. Assuming that cargo then uses the libsodium.a generated by sodiumoxide.
Yes that what I'm investigating currently. The tricky part is getting the path where the lib is installed.
sodiumoxide set something here https://github.com/sodiumoxide/sodiumoxide/blob/master/libsodium-sys/build.rs#L429 Seems to be target dependent but may it works just cargo-magically
I found a way to use user defined build variables. See this PR in sodiumoxyde https://github.com/sodiumoxide/sodiumoxide/pull/344.
Also check my WIP PR https://github.com/jean-airoldie/zeromq-src-rs/pull/9. It should work until sodiumoxyde merge my PR.
Thanks, that was quick.
So basically it should work why any sys crate that links to sodium
and defines both DEP_SODIUM_LIB
and DEP_SODIUM_INCLUDE
.
The PR against sodiumoxyde only works on unix currently. But I think the maintainer is looking into it. Adding windows support should be straightforward, but I don't have access to any windows machine.
Alight so I can't get windows to work since sodiumoxyde
build script is kind of a mess. And its unlikely that they will merge my PR since it only works for unix. Getting the windows script to work is too time consuming for me.
However, I think this PR (in this current repo) achieves your goal, which is to allow support for libsodium
, event though not current library would be compatible.
Could you please add a feature 'vendored' and add libsodium-sys as a dependency if that feature is set? I think this is the only way to tell cargo to build libsodium-sys first.
Please see here https://users.rust-lang.org/t/build-crates-in-specific-order-rust-zmq-libsodium-sys/29276/2
I see. I did not think about the building order. I this case I think we should indeed feature gate the libsodium-sys
dependency.
Ok, so we have a problem. Basically we can only access a build env variable (DEP_SODIUM_LIB
, etc.)
in a build script from a crate that directly depends on libsodium
. But there is no build script in zeromq-src
, indeed this crate only exposes the source code and the logic to build libzmq
from source.
Nevermind I think it got it. However you need libsodium
as a dependency for both zeromq-src
as well as the crate that uses it, which is not ideal.
Alright I think we only need to depend on libsodium once. Basically we would let the user provide the location of the header and the compile libs. I'll try to see if it works.
edit: This works. We only depend on libsodium
once now. See my PR #9.
This was closed by 4491f31b6cb68411d3b03369a6cac22ffb109a96.
However windows does not properly build with libsodium-sys
. I created another issue #12 for that.
Also released on crates.io.
I discovered that there is a new version of rust-zmq 0.9.1 which uses this crate.
Hyperledger Indy is currently using version 0.8 and 0.9 is breaking the API, so we stayed at 0.8 https://github.com/hyperledger/indy-sdk
The good news is that 0.9.1 now has a 'vendored' feature. Tada!
So I upgraded the dependency. https://github.com/AxelNennker/indy-sdk/tree/build_dependencies_from_source
Problem is that zeromq-src defines ZMQ_USE_TWEETNACL so I get some functions defined twice in zeromq-src and in libsodium.
I think there should be feature for this crate that tells it where libsodium.a is. e.g. an environment variable SODIUM_LIB_DIR and another to the include files SODIUM_INCLUDE_DIR
To reproduce the issue you can clone https://github.com/AxelNennker/indy-sdk/tree/build_dependencies_from_source and
cargo build
. Maybe de-install system libzmq and libsodium first.