Linking to openssl fails, but only on Linux?

Hey folks,

So i've run into a very strange error when trying to compile my project on Linux. The compilation works, but the linking appears to fail. Here's the output from the build: Travis CI - Test and Deploy Your Code with Confidence - source code is here: https://github.com/timperrett/diplomat

Seems like there's a problem with OpenSSL, and i've upgraded the build to the latest version which should be compatible with the rust bindings, but no cigar. This works fine for me on a Ubuntu 16.10 VM locally, and also on OSX.

Any advice on this one would be really welcome as i've been wrestling with it for a couple of days!

Thanks in advance!

-- T

Your install-openssl-linux script installs a new copy of OpenSSL next to/on top of the system's built in copy. This will cause the system to become very confused.

It looks like it's finding the headers for the OpenSSL 1.1.0 copy, but linking to the system's older 1.0.x copy. Install your version of OpenSSL to some other directory and point to it with the OPENSSL_DIR environment variable.

Thanks @sfackler, i'll give this a try and report back.

@sfackler so i updated it, Travis CI - Test and Deploy Your Code with Confidence - upon checking the log one can see that it does now indeed use the /opt/openssl custom installation of openssl when compiling the program itself. However, the linking still fails right at the end.

I tried once again removing the original openssl development package (just to be sure it wasn't using that), but it simply resulted in the same error: Travis CI - Test and Deploy Your Code with Confidence

Is there something else i might be missing?

Thanks again!

-- T

It looks like grpcio-sys is pulling in a vendored copy of BoringSSL, which I believe also produces libssl and libcrypto, but has a different ABI. That's probably what's causing the issues:

"-L" "/home/travis/build/timperrett/diplomat/target/release/build/grpcio-sys-54140f9a67891615/out/build/third_party/boringssl/ssl"

Huh, makes sense although I wouldn't have thought to look at that. Short of trying to rework dependencies, is there a way to work around this? AFAICR the OpenSSL binding is coming in from reqwest which in turn uses hyper which pulls in OpenSSL.

I did hear that hyper stopped binding directly because of these kinds of issues, so maybe there are options. Would need to investigate tomorrow :slight_smile:

Not sure - I'd probably ask the grpc people about supporting the system openssl.