Build fails when using reqwest/openssl

[vmalloc]

Reproduction: https://github.com/vmalloc/musl-cross-openssl-issue

When trying to build it via:

CC_x86_64_unknown_linux_musl=x86_64-linux-musl-gcc CXX_x86_64_unknown_linux_musl=x86_64-linux-musl-g++ cargo build --release --target x86_64-unknown-linux-musl

It fails:

cargo:rustc-cfg=const_fn
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_MUSL_OPENSSL_LIB_DIR
X86_64_UNKNOWN_LINUX_MUSL_OPENSSL_LIB_DIR unset
cargo:rerun-if-env-changed=OPENSSL_LIB_DIR
OPENSSL_LIB_DIR unset
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_MUSL_OPENSSL_INCLUDE_DIR
X86_64_UNKNOWN_LINUX_MUSL_OPENSSL_INCLUDE_DIR unset
cargo:rerun-if-env-changed=OPENSSL_INCLUDE_DIR
OPENSSL_INCLUDE_DIR unset
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_MUSL_OPENSSL_DIR
X86_64_UNKNOWN_LINUX_MUSL_OPENSSL_DIR unset
cargo:rerun-if-env-changed=OPENSSL_DIR
OPENSSL_DIR unset
run pkg_config fail: "Cross compilation detected. Use PKG_CONFIG_ALLOW_CROSS=1 to override"

--- 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.

Make sure you also have the development packages of openssl installed.
For example, `libssl-dev` on Ubuntu or `openssl-devel` on Fedora.

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-apple-darwin
$TARGET = x86_64-unknown-linux-musl
openssl-sys = 0.9.47

', /Users/rotemy/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.9.47/build/find_normal.rs:150:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Trying to pass PKG_CONFIG_ALLOW_CROSS=1 doesn't help either:

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.

Make sure you also have the development packages of openssl installed.
For example, `libssl-dev` on Ubuntu or `openssl-devel` on Fedora.

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.

I tried using rust-tls-default-vendored for the reqwest dependency, which gets me a bit further along the compilation but still fails:

# Cargo.toml
[dependencies]
reqwest = { version = "0.9.18", features=["default-tls-vendored"] }

ar: creating archive apps/libapps.a
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: warning for library: apps/libapps.a the table of contents is empty (no object file members in the library define global symbols)
ar: creating archive libssl.a
ar: creating archive libcrypto.a
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: warning for library: libssl.a the table of contents is empty (no object file members in the library define global symbols)
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: warning for library: libcrypto.a the table of contents is empty (no object file members in the library define global symbols)
apps/ca.o: In function `do_revoke':
ca.c:(.text.do_revoke+0x51): undefined reference to `X509_get_subject_name'
ca.c:(.text.do_revoke+0x5d): undefined reference to `X509_NAME_oneline'
ca.c:(.text.do_revoke+0x6a): undefined reference to `X509_get_serialNumber'
ca.c:(.text.do_revoke+0x74): undefined reference to `ASN1_INTEGER_to_BN'
ca.c:(.text.do_revoke+0x88): undefined reference to `BN_is_zero'
ca.c:(.text.do_revoke+0x98): undefined reference to `BN_bn2hex'
ca.c:(.text.do_revoke+0xa5): undefined reference to `BN_free'
ca.c:(.text.do_revoke+0xde): undefined reference to `TXT_DB_get_by_index'
...

Any pointers on what I'm doing wrong are greatly appreciated! thanks in advance!

[vmalloc]

Forgot to mention I'm using OS X Mojave, with the musl-cross homebrew formula installed...

[athei]

I have the same issue. OpenSSL is a notorious difficult project to build. It needs patches for almost anything that is not Linux x64 glibc. Therefore its no surprise that it does not build with musl. I guess its not the fault of this toolchain building project.

That said, as a workaround I just use the rust native SSL Implementation:

[dependencies.reqwest]
version = "0.9"
default-features = false
features = ["rustls-tls"]

Only drawback is that now it uses this on Windows and macOS too instead of the native libraries because cargo does not support selecting different features based on the operating system.

[ryanwoodsmall]

OpenSSL builds fine with musl, including with compilers produced by musl-cross-make.

This:

ar: creating archive apps/libapps.a
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: warning for library: apps/libapps.a the table of contents is empty (no object file members in the library define global symbols)
ar: creating archive libssl.a
ar: creating archive libcrypto.a
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: warning for library: libssl.a the table of contents is empty (no object file members in the library define global symbols)
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: warning for library: libcrypto.a the table of contents is empty (no object file members in the library define global symbols)

certainly does not seem correct for your build. Bits under /Library/Developer on macOS point to native tools and those won't work for cross-compilation.

Along with the CC/CXX settings you already have, you'll need to set at least the ar command up to use the x86_64-linux-musl-ar archiver from the musl-cross-make provided Binutils for Cargo to build Linux-native libraries, possibly the same for ranlib, and you'll probably need a linker set up using either GCC (x86_64-linux-musl-gcc) or Binutils linker (x86_64-linux-musl-ld) in your Cargo config as well.

[kwinsch]

If you compile with LTO ('-flto'), then you need to be carefull with ar, nm and ranlib, since the plugin will be missing. It is always a good idea to use the gcc provided wrappers for the tools, instead of the plain binutils one. I got vanilla OpenSSL to compile with the following ENV exposed:

CC        = "x86_64-linux-musl-gcc"
CXX       = "x86_64-linux-musl-g++"
AS        = "x86_64-linux-musl-as"
AR        = "x86_64-linux-musl-gcc-ar"
NM        = "x86_64-linux-musl-gcc-nm"
RANLIB    = "x86_64-linux-musl-gcc-ranlib"
LD        = "x86_64-linux-musl-ld"
STRIP     = "x86_64-linux-musl-strip"

[richfelker]

Do you still believe this is an issue needing action from the musl-cross-make side? I'm closing old issues and would like to close this if not.