Builds on windows and linux fail with OpenSSL installed.

[Aarowaim]

After following the suggestion to use pkg_config, this library will still not compile. The issue seems to be that openssl is installed but uses the environment variable OPENSSLDIR. Rust-OpenSSL attempts to find openssl in OPENSSL_DIR. I had a similar issue compiling this package on windows.

user@computer:~/________$ cargo build
   Compiling openssl-sys v0.9.19
error: failed to run custom build command for `openssl-sys v0.9.19`
process didn't exit successfully: `/home/________/__________/target/debug/build/openssl-sys-ba6ccebcccca8f64
/build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_LIB_DIR
cargo:rerun-if-env-changed=OPENSSL_LIB_DIR
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_INCLUDE_DIR
cargo:rerun-if-env-changed=OPENSSL_INCLUDE_DIR
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_DIR
cargo:rerun-if-env-changed=OPENSSL_DIR
run pkg_config fail: "`\"pkg-config\" \"--libs\" \"--cflags\" \"openssl\"` did not exit successfully: exit code: 1\
n--- stderr\nPackage openssl was not found in the pkg-config search path.\nPerhaps you should add the directory con
taining `openssl.pc\'\nto the PKG_CONFIG_PATH environment variable\nNo package \'openssl\' found\n"
--- stderr
thread 'main' panicked at '
Could not find directory of OpenSSL installation, and this `-sys` crate cannot
proceed without this knowledge. If OpenSSL is installed and this crate had
trouble finding it,  you can set the `OPENSSL_DIR` environment variable for the
compilation process.
If you're in a situation where you think the directory *should* be found
automatically, please open a bug at https://github.com/sfackler/rust-openssl
and include information about your system as well as this message.
    $HOST = x86_64-unknown-linux-gnu
    $TARGET = x86_64-unknown-linux-gnu
    openssl-sys = 0.9.19
', /home/_________/.cargo/registry/src/____________/openssl-sys-0.9.19/build.rs:210:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.
user@computer:~/________$ openssl version -d
OPENSSLDIR: "/usr/lib/ssl"```

[Aarowaim]

libssl-dev is installed as well. I've done a bit of troubleshooting and still have this issue (though I've made progress, something is still wrong).

After setting OPENSSL_DIR="usr/lib/ssl":

thread 'main' panicked at 'OpenSSL library directory does not exist: /usr/lib/ssl/lib', /home/_______/.cargo/
registry/src/_______________/openssl-sys-0.9.19/build.rs:69:8
note: Run with `RUST_BACKTRACE=1` for a backtrace.

After setting OPENSSL_DIR="usr":

thread 'main' panicked at 'OpenSSL libdir at `/usr/lib` does not contain the required files to either statically or
 dynamically link OpenSSL', /home/______/.cargo/registry/src/_______/openssl-sys-0.9.19/
build.rs:532:12
note: Run with `RUST_BACKTRACE=1` for a backtrace.

[Aarowaim]

After confirming that any dependencies in this issue were installed, I am still receiving this panic. As far as I'm aware I have all dependencies (libssl-dev, pkg-config, openssl) installed and should not have issues.

[sfackler]

The OPENSSL_DIR environment variable is unrelated to OpenSSL's own OPENSSLDIR value.

What do pkg-config --cflags openssl and pkg-config --libs openssl return? Where on the filesystem are libcrypto.so and openssl.h?

[Aarowaim]

I had formatted and reinstalled all dependencies from scratch. The issue persisted. I switched to a more recent branch of the project being compiled. The linux environment is identical to the one producing the error, only the code changed, and tokio/chan were added and... openssl-sys compiled just fine?

pkg-config --cflags openssl: Blank line
pkg-config --libs openssl : -lssl -lcrypto
Neither libcrypto.so nor openssl.h are located in /usr/lib/ssl

---

After some googling, I discovered that there's a way to quickly locate files installed by an apt-get command by using apt-file. It seems the libssl-dev directory is not one of those searched by rust-openssl.

apt-file list libssl-dev | grep libssl.a | awk '{ print $2 }': /usr/lib/x86_64-linux-gnu/libssl.a
apt-file list libssl-dev | grep libcrypto.a | awk '{ print $2 }': /usr/lib/x86_64-linux-gnu/libcrypto.a

apt-file list libssl-dev | grep libcrypto.so | awk '{ print $2 }': /usr/lib/x86_64-linux-gnu/libcrypto.so
apt-file list libssl-dev | grep openssl.h | awk '{ print $2 }': /usr/include/x86_64-linux-gnu/openssl/hmac.h

openssl.h does not seem to exist, but libssl does (not as header files):
apt-file list libssl-dev | grep libcrypto.so | awk '{ print $2 }': /usr/lib/x86_64-linux-gnu/libssl.so

---

So, it seems that libssl and libcrypto are both available for static or dynamic linking on this system, but do not contain any header files.

cargo build on the failing branch tries to compile openssl v0.9.19 and openssl-sys v0.9.19 and fails as my previous posts indicate. The working branch appends futures, tokio-io, tokio-core, and chan to Cargo.toml. The working branch compiles the same two openssl dependencies successfully in an identical linux environment, suggesting that the other crates added have successful workarounds for this issue.

The failing branch compiles successfully by setting OPENSSL_DIR = '/usr/lib/x86_64-linux-gnu'.

Thankfully, the issue on my system has been solved, but this case does seem worth automation. Given the relative simplicity of the fix along with the fact that it's an installation path of apt-get install libssl-dev, I suggest that the directory should be discovered automatically or that the user should be given instructions on how to locate the directory on major distros.

[sfackler]

I am not aware of anything other crates can do to change the behavior of openssl-sys remotely.

I don't understand how setting OPENSSL_DIR to /usr/lib/x86_64-linux-gnu would work, unless there are /usr/lib/x86_64-linux-gnu/lib and /usr/lib/x86_64-linux-gnu/include directories which would not match up with the filesystem layout I'd expect.

Everything should work fine as long as you have OpenSSL headers installed (via libssl-dev) and let pkg-config do its thing. Are there a set of steps you can show me that reproduce the issue starting from something like a base Docker image for whatever distro you're using?

[Aarowaim]

Yeah, that's what I'm thinking. It's interesting that it fails this way. I'm using Google Cloud Platform's debian-9-stretch-v20171025 Compute Engine image as the base. I'll see if I can get a clean repro for you, and maybe even find a way to export the image so you can test it.

---

Hmm, the problem seems to have gone away. The only differences this time were installing sshguard, not installing postfix, and marking google-cloud-sdk as on hold. libssl is still located in the same place (/usr/lib/x86_64-linux-gnu), and pkg-config still gives the same outputs as before.

I can only assume one of the packages (postfix or pkg-config) in the other VM was misconfigured and starting from scratch resolved the problem. Weird that it failed on one branch of a git project but not the other.

Oh well, I'm content that the problem is resolved and that there's a way to fix it on misconfigured systems. Thanks for rubber ducking with me, and maybe you'll bump into similar issues in the future and have a bit more info to troubleshoot with.

---

The working set of commands:

Fixing Google Cloud SDK issue https://issuetracker.google.com/issues/36323738

$ sudo apt-mark hold google-cloud-sdk

Upgrading

$ sudo apt-get -y upgrade && sudo apt-get -y update
$ sudo apt-get -y install gcc sshguard pkg-config libssl-dev git

Confirming libssl-dev installed

$ pkg-config --libs openssl
> -lssl -lcrypto
$ pkg-config --cflags openssl
>

Installing rustup

$ sudo curl https://sh.rustup.rs -sSf | sh
$ 1
$ source $HOME/.cargo/env

Getting project and compiling

$ git clone https://github.com/Aarowaim/vindinium-rs.git
$ cd vindinium-rs
$ git checkout master
$ cargo build

[sfackler]

Cool, no worries! Glad things are working now.

[newmankyle]

I had the same problem as @Aarowaim , however setting OPENSSL_DIR didn't work for me. I had to set the environment variable OPENSSL_LIB_DIR='/usr/lib/x86_64-linux-gnu'

[adrienperonnet]

Similar problem with Google image https://console.cloud.google.com/marketplace/details/bitnami-launchpad/elk?filter=category:others (on last version : 6.6.1-0)
I had to set my PKG_CONFIG_PATH env variable to /usr/lib/x86_64-linux-gnu/pkgconfig/ to make my build work:

export PKG_CONFIG_PATH=/usr/lib/x86_64-linux-gnu/pkgconfig/

[r-arias]

export PKG_CONFIG_PATH=/usr/lib/x86_64-linux-gnu/pkgconfig/

this gets me every time! I have to duckduckgo for hours and try several combinations of OPENSSL_LIB_DIR and OPENSSL_INCLUDE_DIR that don't seem to work.

Thank you @adrienperonnet !

[breggle]

In my case, set the following env solved the problem, which just suggest where to find the openssl header files and lib.so. Forget about OPENSSL_DIR env, which just suggests how to find the above two, but different system has different setting whichs lead to bug.

export OPENSSL_LIB_DIR="/usr/lib/x86_64-linux-gnu"
export OPENSSL_INCLUDE="/usr/include/openssl"

[outliners]

I think the export OPENSSL_INCLUDE part should be OPENSSL_INCLUDE_DIR as it costed me one hour to realize it.

so, it should be:

export OPENSSL_LIB_DIR="/usr/lib/x86_64-linux-gnu"
export OPENSSL_INCLUDE_DIR="/usr/include/openssl"

[mankinskin]

Arch Linux:

% sudo pacman -S openssl-1.0

export OPENSSL_LIB_DIR="/usr/lib/openssl-1.0"
export OPENSSL_INCLUDE_DIR="/usr/include/openssl-1.0"

[bonecountysheriff]

Setting OPENSSL_DIR to /usr helps. The wiki page (https://wiki.archlinux.org/index.php/OpenSSL#Configuration) suggests setting it to /etc/ssl but that didn't work.

[istavros]

This worked for me on
Ubuntu 22.04.2 arm64:

sudo apt install libssl-dev

export OPENSSL_DIR="usr/lib/ssl"
export OPENSSL_INCLUDE_DIR="/usr/include/openssl"
export OPENSSL_LIB_DIR="/usr/lib/aarch64-linux-gnu"

[amirgohar-AG]

for me i had to do the following:

export OPENSSL_LIB_DIR="/usr/lib/x86_64-linux-gnu"
export OPENSSL_DIR=/usr

[bortolottidev]

Yeah, that's what I'm thinking. It's interesting that it fails this way. I'm using Google Cloud Platform's debian-9-stretch-v20171025 Compute Engine image as the base. I'll see if I can get a clean repro for you, and maybe even find a way to export the image so you can test it.

Hmm, the problem seems to have gone away. The only differences this time were installing sshguard, not installing postfix, and marking google-cloud-sdk as on hold. libssl is still located in the same place (/usr/lib/x86_64-linux-gnu), and pkg-config still gives the same outputs as before.

I can only assume one of the packages (postfix or pkg-config) in the other VM was misconfigured and starting from scratch resolved the problem. Weird that it failed on one branch of a git project but not the other.

Oh well, I'm content that the problem is resolved and that there's a way to fix it on misconfigured systems. Thanks for rubber ducking with me, and maybe you'll bump into similar issues in the future and have a bit more info to troubleshoot with.

The working set of commands:

Fixing Google Cloud SDK issue https://issuetracker.google.com/issues/36323738

$ sudo apt-mark hold google-cloud-sdk

Upgrading

$ sudo apt-get -y upgrade && sudo apt-get -y update
$ sudo apt-get -y install gcc sshguard pkg-config libssl-dev git

Confirming libssl-dev installed

$ pkg-config --libs openssl
> -lssl -lcrypto
$ pkg-config --cflags openssl
>

Installing rustup

$ sudo curl https://sh.rustup.rs -sSf | sh
$ 1
$ source $HOME/.cargo/env

Getting project and compiling

$ git clone https://github.com/Aarowaim/vindinium-rs.git
$ cd vindinium-rs
$ git checkout master
$ cargo build

Got the same problem on ubuntu WSL. After following your steps:
Status: 200 OK
Hooray! Saved my day, thank you!

[JamesTheAwesomeDude]

for those on Windows using the OpenSSL distributed by slproweb and compiling with MSVC, the key is the second line here

set OPENSSL_DIR=%PROGRAMFILES%\OpenSSL-Win64
set OPENSSL_LIB_DIR=%PROGRAMFILES%\OpenSSL-Win64\lib\VC\x64\MD