safe_client_libs compilation problem - rust-openssl

Hello. I wanted to compile a 32-bit version of client libs. I installed an i386 Debian Sid from mini.iso with packages: openssh, cargo (so rust as dependency), git, curl, make, libssl-dev, pkg-config.

git clone --depth 1
cd safe_client_libs/safe_app
cargo build --release --features "use-mock-routing" --target=i686-unknown-linux-gnu

And I get an error:

maciek@debsid32:~/safe_client_libs/safe_app$ cargo build --release --features "use-mock-routing" --target=i686-unknown-linux-gnu
   Compiling openssl v0.9.24
   Compiling num-traits v0.1.43
error: failed to run custom build command for `openssl v0.9.24`
process didn't exit successfully: `/home/maciek/safe_client_libs/target/release/build/openssl-74e276710c5b53dd/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Unable to detect OpenSSL version', /home/maciek/.cargo/registry/src/
note: Run with `RUST_BACKTRACE=1` for a backtrace.

warning: build failed, waiting for other jobs to finish...
error: build failed

Is there a workaround? Seems like it’s an old version of openssl crate code and it cannot detect a 1.1.1 version of openssl:

1 Like

Downgrading to openssl versions from Debian stretch or even jessie-backports does not work.

I think 32bit is not supported anymore.

I’ve managed to compile a 32-bit version in February. Maybe we are not that far from that?

Are you sure the problem is related to a processor architecture?

@loziniak, I just know that x86 was removed as being Tier-1 platform supported by us, I honestly don’t know if it’s still possible to build it for that architecture or not, perhaps @marcin or @nbaksalyar can give more details

This looks like a recognized problem in the openssl crate.

Luckily some users there have reported workarounds. Can you give them a try @loziniak?


Before I saw this topic I made an issue about this, but in the crust repository (Fail to build on hosts with openssl 1.1.1 · Issue #1012 · maidsafe-archive/crust · GitHub). I encountered it while trying to build the crust test on a Raspberry Pi.

I solved it by the mentioned workaround:


Currently I’ve tried downloading rust_sodium sources, replacing reqwest version with newer one (to bump openssl-sys version to fixed one) in rust_sodium-sys/Cargo.toml and play with patching Cargo.toml files in safe_authenticator, safe_app and safe_core to use downloaded sources instead of crates from I also don’t know rust and cargo at all, so all it was just a blind trials with no success. Perhaps now it’s time for workarounds from your links, thanks!

(some notes below)

crates dependencies (from Cargo.lock):
openssl-sys <- openssl <- native-tls <- reqwest                <- rust_sodium-sys <- rust_sodium <- safe_authenticator
					tokio-tls <- hyper-tls					    
					hyper-tls <- reqwest


rust_sodium = { path = '/home/maciek/rust_sodium', version = "~0.10.0" }

path = '/home/maciek/rust_sodium'
version = "~0.10.0"

rust_sodium = { path = '/home/maciek/rust_sodium', version = "~0.10.0" }
1 Like

Good luck. Ping me if you need help with anything!

1 Like

I used a workaround from the rust-openssl #994 issue. I use this command to start compilation:

OPENSSL_LIB_DIR="/usr/lib/i386-linux-gnu" OPENSSL_INCLUDE_DIR="/usr/include/openssl" cargo build --release --features "use-mock-routing" --target=i686-unknown-linux-gnu

At first, I noticed Compiling openssl v0.9.24 message that filled me with hope, but after some time, I saw that message second time, this time with errors not related to a libssl version, but to a source code:

It’s probably my fault, but I don’t know what I’m doing wrong.


OPENSSL_LIB_DIR="/usr/lib/i386-linux-gnu" doesn’t seem right? I think it should point to an existing directory containing the openssl library. No idea whether that’s causing the issue you’re seeing though.

OPENSSL_INCLUDE_DIR="/usr/include/openssl" should also be OPENSSL_INCLUDE_DIR="/usr/include/openssl-1.0" I think. (Check if they exist.)

@bzee, this is based on Debian packages filelists: libssl1.0-dev and libssl1.0.2

1 Like

Ah, I see. :+1:

I wonder: where is the (soft?) link located? I think the OPENSSL_LIB_DIR should refer to the directory that contains that soft link. Seems to be correct on second look.

@loziniak Can you please try this workaround, if you haven’t already?

If that doesn’t work, you can open an issue for rust-openssl, as it looks to be a problem with their source code.

Good luck, I hope these issues get resolved!

1 Like

One more thing @loziniak, can you try running cargo clean and compiling fresh? It might solve your error… 0.9.24 compiles fine for me :confused:

1 Like

Woah, success! cargo clean and OPENSSL_LIB_DIR wokaround did the job. I don’t know why the second compilation pass has started the last time… Thank you all!


Awesome! :partying_face:


I’ve had a couple of days looking after my poorly son, so had a crack at getting some SAFENetwork dev work underway again. However, I had some similar problems to this thread.

I am using Ubuntu 18.10 with libssl 1.1.1.

For me, I updated the Cargo.toml to use rust_sodium = "~0.10.1". Then cargo build --release seemed to complete successfully.

I’m not sure whether this has broken other things, but it compiled at least. I’m new to Rust and the code base, so I haven’t tried anything out yet. My plan is just to experiment and hopefully do some Java dev on SAFE Network again.

I think the ‘Rust way’ would be to use cargo update --package rust_sodium so it updates the Cargo.lock file. I used this last week and I couldn’t verify whether this broke the build or didn’t. By the way, which Cargo.toml did you edit? safe_client_libs has multiple crates.

1 Like