Skip to content
This repository has been archived by the owner on Jan 12, 2022. It is now read-only.

Unable to detect Open SSL version #19

Closed
jamesray1 opened this issue Nov 2, 2018 · 2 comments
Closed

Unable to detect Open SSL version #19

jamesray1 opened this issue Nov 2, 2018 · 2 comments

Comments

@jamesray1
Copy link
Contributor

jamesray1 commented Nov 2, 2018

After following the README instructions I got the following:

[jray@jr-dl shasper]$ cargo run -- --chain dev
   Compiling openssl v0.9.24
   Compiling serde_json v1.0.28
   Compiling url v1.7.1
   Compiling num-integer v0.1.39
error: failed to run custom build command for `openssl v0.9.24`
process didn't exit successfully: `/home/jray/r/shasper/target/debug/build/openssl-d6940fa3998f9474/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Unable to detect OpenSSL version', /home/jray/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/openssl-0.9.24/build.rs:16:14
note: Run with `RUST_BACKTRACE=1` for a backtrace.

warning: build failed, waiting for other jobs to finish...
error: build failed
[jray@jr-dl shasper]$ RUST_BACKTRACE=1 cargo run -- --chain dev
   Compiling openssl v0.9.24
   Compiling ctrlc v3.1.1
   Compiling crossbeam-epoch v0.3.1
   Compiling crossbeam-epoch v0.5.2
error: failed to run custom build command for `openssl v0.9.24`
process didn't exit successfully: `/home/jray/r/shasper/target/debug/build/openssl-d6940fa3998f9474/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Unable to detect OpenSSL version', /home/jray/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/openssl-0.9.24/build.rs:16:14
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:477
   5: std::panicking::begin_panic
             at libstd/panicking.rs:411
   6: build_script_build::main
             at ./build.rs:16
   7: std::rt::lang_start::{{closure}}
             at libstd/rt.rs:74
   8: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
   9: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:103
  10: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  11: std::rt::lang_start
             at libstd/rt.rs:74
  12: main
  13: __libc_start_main
  14: _start

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

Related: sfackler/rust-openssl#994. 0.9 needs to be updated in dependencies to 0.10.15, 0.9 is not supported any more.

TL;DR: none of the below seems to help.

Looking at the dependency graph in #20, it is too jumbled to easily identify what are dependencies of openssl. So looking at the cargo-count.dot file, openssl is a build dependency of native-tls and an optional dependency of ws v0.7.8. The latest version for ws is 0.7.9, which uses open-ssl 0.10, still as an optional dependency. Both ws and native-tls are build dependencies (green diamonds). tokio-tls and websocket depend on native-tls, and substrate-telemetry depends on ws, etc. native-tls's latest version is 0.2.2, using open-ssl 0.10.15, which is currently the latest version (on all platforms except for windows, Mac, and iOS). So it seems like the solution to this is to change substrate-telemetry to ws 0.7.9, and use versions of tokio-tls (0.2) and websocket (0.21.1) that use native-tls 0.2.2, or just native-tls 0.2. However, substrate-telemetry already uses ws ^0.7. OTOH, ws 0.7.0 optionally uses open-ssl ^0.9, so I think that may be the issue. I made a PR to update ws to 0.7.9 in substrate.

The tokio-tls readme says to also add native-tls 0.2 as a dependency to your project's toml., and also just use tokio-tls 0.2 (rather than 0.2.2). Websocket 0.21.0 is a dependency of libp2p-websocket, could change that to 0.21.1. websocket 0.21.1 also depends on tokio-tls 0.2.0 (which could be changed to 0.2) and native-tls 0.2.1; I made a PR to update native-tls to 0.2.2: websockets-rs/rust-websocket#197. However, that doesn't help as native-tls 0.2.1 used open-ssl ^0.10.11.

@vi
Copy link

vi commented Nov 2, 2018

websocket 0.21.1 also depends on tokio-tls 0.2.0 (which could be changed to 0.2)

0.2.0 and 0.2 are the equivalent version requirement specifications. It means 0.2.*. For pinning it to exact version =0.2.0 notation is used.

@sorpaas
Copy link
Member

sorpaas commented Dec 22, 2018

@jamesray1 Looks like this should have been fixed by paritytech/substrate#931. Let me know if you still have this issue!

@sorpaas sorpaas closed this as completed Dec 22, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants