How to build an executable that depends on curl for x86_64-unknown-linux-musl - rust

I am on an amd64 Debian machine, and am trying to build a x86_64-unknown-linux-musl executable. I have this in my Cargo.toml:
[dependencies]
curl = "0.4"
When I run cargo build --target=x86_64-unknown-linux-musl I get
this:
error: failed to run custom build command for `libz-sys v1.0.10`
process didn't exit successfully: `/tmp/foo/target/debug/build/libz-sys-c20da5f29c41e515/build-script-build` (exit code: 101)
--- stdout
OPT_LEVEL = Some("0")
PROFILE = Some("debug")
TARGET = Some("x86_64-unknown-linux-musl")
debug=true opt-level=0
HOST = Some("x86_64-unknown-linux-gnu")
TARGET = Some("x86_64-unknown-linux-musl")
TARGET = Some("x86_64-unknown-linux-musl")
HOST = Some("x86_64-unknown-linux-gnu")
CC_x86_64-unknown-linux-musl = None
CC_x86_64_unknown_linux_musl = None
TARGET_CC = None
CC = None
HOST = Some("x86_64-unknown-linux-gnu")
CROSS_COMPILE = None
TARGET = Some("x86_64-unknown-linux-musl")
HOST = Some("x86_64-unknown-linux-gnu")
CFLAGS_x86_64-unknown-linux-musl = None
CFLAGS_x86_64_unknown_linux_musl = None
TARGET_CFLAGS = None
CFLAGS = None
running: "./configure" "--prefix=/tmp/foo/target/x86_64-unknown-linux-musl/debug/build/libz-sys-e109627694e9981e/out"
Compiler error reporting is too harsh for ./configure (perhaps remove -Werror).
** ./configure aborting.
--- stderr
thread 'main' panicked at 'failed to run successfully: exit code: 1', /home/tshepang/.cargo/registry/src/github.com-1ecc6299db9ec823/libz-sys-1.0.10/build.rs:189
When I re-run it:
error: failed to run custom build command for `openssl-sys v0.9.6`
process didn't exit successfully: `/tmp/foo/target/debug/build/openssl-sys-ac9c042b062dad1d/build-script-build` (exit code: 101)
--- 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-musl
openssl-sys = 0.9.6
All works well when I build natively, i.e. cargo build --target=x86_64-unknown-linux-gnu.
Searching around, I learned about an environment variable, PKG_CONFIG_ALLOW_CROSS:
PKG_CONFIG_ALLOW_CROSS=true cargo build --target=x86_64-unknown-linux-musl
In doing that, I also found that I was missing the Debian package
named libcurl4-openssl-dev.
Running ldd target/target/x86_64-unknown-linux-musl/debug/foo
indicated the executable is dynamically linked, then searching
further, I learned about another environment variable,
PKG_CONFIG_ALL_STATIC:
PKG_CONFIG_ALL_STATIC=true PKG_CONFIG_ALLOW_CROSS=true cargo build --target=x86_64-unknown-linux-musl
That revealed a whole bunch of missing deps, all of which (luckily)
had Debian dependencies. But installing all of them did not help, as,
in the end, I was still sitting with an executable that wasn't
statically linked .

I gave in and ended up using cross:
cargo install cross
cross build --target=x86_64-unknown-linux-musl
This was just too easy, and you will find the executable in target/x86_64-unknown-linux-musl/debug.

The curl crate depends (directly or indirectly) on the two crates libz-sys and openssl-sys.
A crate whose name ends in "-sys" is generally a set of FFI (foreign function interface) bindings to a native C library.
Building such a "-sys" crate requires linking to the native library. If your target is x86_64-unknown-linux-musl, then you must link to a native library built against musl, not glic. However, most of the packages you will find in the repositories of your distribution provide libraries built against glibc.
The solution is to build yourself the libraries you need, linking to musl instead of glibc.
I don't have access to a Debian installation, but on Ubuntu 16.04 this looks like this for OpenSSL:
# this package provides the "musl-gcc" wrapper
apt-get install musl-tools
# you will also need these, if they are not installed yet
apt-get install pkg-config xutils-dev build-essential
# Download and build OpenSSL against musl
VERS=1.0.2j
export CC=musl-gcc
export MUSL_PREFIX=/usr/local/musl
export C_INCLUDE_PATH="$MUSL_PREFIX/include/"
curl -O https://www.openssl.org/source/openssl-$VERS.tar.gz
tar xvzf openssl-$VERS.tar.gz
cd openssl-$VERS
./config --prefix "$MUSL_PREFIX"
make depend
make
sudo make install
export OPENSSL_DIR=/usr/local/musl/
export OPENSSL_STATIC=1
Once you have one the same for libz (I haven't tried to built it), you should then be able to build your crate:
cargo build --target=x86_64-unknown-linux-musl
and the resulting binary will be in target/x86_64-unknown-linux-musl/debug/<binary_name>
The cross tool does basically this, but inside a Docker container as to keep your host machine clean.
The binary produced by this build should be statically linked, and not depend even on glibc. This also means that it will be bigger* and that you will need to take care yourself of upgrading any dependency (especially OpenSSL) if a security issue is found in one of them.
*You may want to use strip on the released binary.

Related

Rust flo_draw graphics library is not building

The issue I'm having are regarding a copy-pasted flo_draw example program. I am using vscode and the rust-anylizer extension. It tells me failed to run build scripts, check server logs for more information apon copying the code in. I don't know how to check these or what they are. Using cargo run from the terminal yields no better results.
I tried to copy in the code below:
// src.main.rs
use flo_draw::*;
use flo_draw::canvas::*;
fn main() {
with_2d_graphics(|| {
let canvas = create_canvas_window("Hello, world");
});
}
$ cargo run
Compiling futures v0.3.25
Compiling semver v0.11.0
Compiling flo_render_gl_offscreen v0.3.0
Compiling allsorts v0.5.1
Compiling winit v0.24.0
error: failed to run custom build command for `flo_render_gl_offscreen v0.3.0`
Caused by:
process didn't exit successfully: `/<path to program>/target/debug/build/flo_render_gl_offscreen-9d539a79f1cb257c/build-script-build` (exit status: 101)
\--- stderr
thread 'main' panicked at 'Unable to find libclang: "couldn't find any valid shared libraries matching: \['libclang.so', 'libclang-*.so', 'libclang.so.*', 'libclang-*.so.*'\], set the `LIBCLANG_PATH` environment variable to a path where one of these files can be found (invalid: \[\])"', /<path to home>/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.54.0/src/lib.rs:1959:31
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
flo_draw, or, more specifically, one of its dependencies, links to the external C library and therefore have to generate the matching API. This is done using bindgen, which requires clang to be installed in your system.
Installation instructions from the linked page:
Debian-based Linuxes
# apt install llvm-dev libclang-dev clang
Ubuntu 18.04 provides the necessary packages directly.
Arch
# pacman -S clang
Fedora
# dnf install clang-devel

Cross compile shared library for armv5te-unknown-linux-gnueabi Rust [Mindstorm Ev3dev]

Parameters:
source = x86_x64 windows 10 or x86_x64 linux (ubuntu wsl)
target = armv5te linux
target_type = cdylib
target_glibc = 2.24
language = rust
build_tool = cargo
compiler = rustc
(The target is a Lego Mindstorm running a linux image from Ev3dev)
Cargo Configuration:
[package]
name = "ev3"
version = "0.1.0"
edition = "2021"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
jni = "0.19"
ev3dev-lang-rust = { version = "0.12.1", features=["screen"]}
jni_proc_macro= {path= "./jni_proc_macro"}
[lib]
crate-type= ["cdylib"]
[workspace]
members= ["jni_proc_macro"]
Build Configuration:
[build]
target = "armv5te-unknown-linux-gnueabi"
[target.armv5te-unknown-linux-gnueabi]
linker = "rust-lld"
Build Error:
error: linking with `rust-lld` failed: exit code: 1
|
= note: {...}
= note: rust-lld: error: unable to find library -lgcc_s
rust-lld: error: unable to find library -lutil
rust-lld: error: unable to find library -lrt
rust-lld: error: unable to find library -lpthread
rust-lld: error: unable to find library -lm
rust-lld: error: unable to find library -ldl
rust-lld: error: unable to find library -lc
error: could not compile `ev3` due to previous error
As the error suggests the linker is missing libraries. I found no clear solution where I can download and or provide these dependencies.
My question is, A is there a diffrent way to build this successfully or B how do I solve these dependencies.
The result needs to be a shared library (.so) for linux and armv5te
Requirements
wsl or linux installed
cargo and rustc installed
(everthing is done in wsl/linux)
Prep/Build
Install cross on cargo
cargo install cross --git https://github.com/cross-rs/cross
Install docker
Clone the cross repository
Navigate into the docker folder
Create a new file with the name "Dockerfile.armv5te-unknown-linux-gnueabi-cross"
Paste this in the new file:
FROM ubuntu:16.04
ARG DEBIAN_FRONTEND=noninteractive
COPY common.sh lib.sh /
RUN /common.sh
COPY cmake.sh /
RUN /cmake.sh
COPY xargo.sh /
RUN /xargo.sh
RUN apt-get update && apt-get install --assume-yes --no-install-recommends \
g++-arm-linux-gnueabi \
crossbuild-essential-armel \
libc6-dev-armel-cross
COPY deny-debian-packages.sh /
RUN TARGET_ARCH=armel /deny-debian-packages.sh \
binutils \
binutils-arm-linux-gnueabi
# Qemu is disabled since we've changed the scripts to require newer Python versions.
#COPY qemu.sh /
#RUN /qemu.sh arm
COPY qemu-runner base-runner.sh /
ENV CROSS_TOOLCHAIN_PREFIX=arm-linux-gnueabi-
ENV CROSS_SYSROOT=/usr/arm-linux-gnueabi
ENV CARGO_TARGET_ARMV5TE_UNKNOWN_LINUX_GNUEABI_LINKER="$CROSS_TOOLCHAIN_PREFIX"gcc \
CARGO_TARGET_ARMV5TE_UNKNOWN_LINUX_GNUEABI_RUNNER="/qemu-runner arm" \
AR_armv5te_unknown_linux_gnueabi="$CROSS_TOOLCHAIN_PREFIX"ar \
CC_armv5te_unknown_linux_gnueabi="$CROSS_TOOLCHAIN_PREFIX"gcc \
CXX_armv5te_unknown_linux_gnueabi="$CROSS_TOOLCHAIN_PREFIX"g++ \
BINDGEN_EXTRA_CLANG_ARGS_armv5te_unknown_linux_gnueabi="--sysroot=$CROSS_SYSROOT" \
QEMU_LD_PREFIX="$CROSS_SYSROOT" \
RUST_TEST_THREADS=1 \
PKG_CONFIG_PATH="/usr/lib/arm-linux-gnueabi/pkgconfig/:${PKG_CONFIG_PATH}"
Make sure the project uses "LF" newlines. if not this fixes it.
Compile the custom cross/docker build using the following command in the root of the cloned repository:
cargo build-docker-image armv5te-unknown-linux-gnueabi-cross
This will create a new docker image that will be used to compile the rust code.
Then navigate to your target project folder and run:
export CROSS_TARGET_ARMV5TE_UNKNOWN_LINUX_GNUEABI_IMAGE=ghcr.io/cross-rs/armv5te-unknown-linux-gnueabi-cross:local
(Do not close this terminal)
Now add the following to the Cargo.toml file:
[package.metadata.cross.build]
default-target = "armv5te-unknown-linux-gnueabi"
now you can run:
cross build
Many cargo options like "--release" can be used (for more info have a look at cross in the credits)
Credits
MeetTitan(Stackoverflow) who recomended me to use cross
Cross project(GitHub) which powers the whole solution
Custom cross version discussion(Cross Github)
Alexhuszagh(Cross Github) who showed me how to build a custom cross version
Emilgardis(Cross Github) who explained the newline bug

pkg-config error during Rust cross-compilation

I am getting this error when I try to cross-compile some Rust; does anyone know what I should be doing?
This happens when I run cargo build --target aarch64, I get:
Compiling glib-sys v0.10.1
error: failed to run custom build command for `glib-sys v0.10.1`
...
pkg-config has not been configured to support cross-compilation.
Install a sysroot for the target platform and configure it via
PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH, or install a
cross-compiling wrapper for pkg-config and set it via
PKG_CONFIG environment variable.
I might have asked this before a year or so ago, but anyway I cannot find any answer. I have tried adding various lines to my Cargo.toml but nothing seems to help.
The relevant part of Cargo.toml has:
[target.'cfg(target_os = "android")'.dependencies]
cairo = "0.0.4"
freetype = "0.7.0"
glib = "0.14.2"
openssl = "0.10.36"
openssl-sys = {version = "0.9.66", features = ["vendored"]}
There is probably a one-line answer to this; can anyone help me please.
You could try adding feature vendored for the openssl crate.
openssl = { version = "0.10.35", features = ["vendored"] }
reference
I'm also new to rust so there may be some mistakes in my answer.
So the warning suggests that the pkg-config is not correctly set, which suggests that this is not a rust issue, it's a pkg-config issue.
If you check the doc of pkg-config, you might see there's an environment variable called PKG_CONFIG_SYSROOT_DIR which "is useful for cross compilation". What you'll need to do is to run cargo with this environment set, e.g. PKG_CONFIG_SYSROOT_DIR=/usr/x86_64-w64-mingw32/ cargo build, where /usr/x86_64-w64-mingw32 contains all the file necessary for cross build for windows (as you can see from the name).
I'm not sure how to cross compile for aarch64, and I'm not sure how to add environment variable for cargo build, but I hope my experience above can give you some hint.

How do I cross-compile openssL libraries on Mac OS by rust?

When I was compiling a Linux binary on MacOS, I encountered this problem:
It looks like the rust library "openssl-sys v0.9.61" is bound to the C library of MacOS. can't link to linux.
cargo build --release --target=x86_64-unknown-linux-musl
Compiling openssl-sys v0.9.61
error: failed to run custom build command for `openssl-sys v0.9.61`
Caused by:
process didn't exit successfully: `~/test/../bin/release/build/openssl-sys-96148dcd52905249/build-script-main` (exit status: 101)
--- stdout
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
cargo:rerun-if-env-changed=OPENSSL_NO_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_x86_64-unknown-linux-musl
cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_x86_64_unknown_linux_musl
cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_ALLOW_CROSS
cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS
cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-musl
cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_musl
cargo:rerun-if-env-changed=TARGET_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-musl
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_musl
cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_SYSROOT_DIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
run pkg_config fail: "pkg-config has not been configured to support cross-compilation.\n\n Install a sysroot for the target platform and configure it via\n PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH, or install a\n cross-compiling wrapper for pkg-config and set it via\n PKG_CONFIG environment variable."
--- 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.61
', ~/.cargo/registry/src/openssl-sys-0.9.61/build/find_normal.rs:174:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I found that some people also encountered this problem:
https://www.andrew-thorburn.com/cross-compiling-a-simple-rust-web-app/
It's true that you need to determine which rust dependencies use openssl during the cross compile link phase. In my project, reqwest and mysql dependencies apparently use them when cross-compiling. I had a similar issue when cross-compiling from my mac to x86_64 or aarch64 (arm) linux targets on my mac m1. The linker was failing when linking to openssl.. The trick is to add openssl crate to your project. There is good information here: https://docs.rs/openssl/latest/openssl/
here are the steps with other helpful links also:
1.rustup add target (this is AMD64 linux)
rustup target add x86_64-unknown-linux-musl
for (arm7 linux)
rustup target add aarch64-unknown-linux-musl
1(a) add the xplatform linker
brew install FiloSottile/musl-cross/musl-cross
for x86 and arm7 support:
brew install FiloSottile/musl-cross/musl-cross --with-aarch64 --with-x86_64
1(b) add openssl crate
https://docs.rs/openssl/latest/openssl/
may need to install openssl (see directions)
brew install openssl#1.1
[dependencies]
openssl = { version = "0.10", features = ["vendored"] }
2. modify ~/.cargo/config.toml
add link targets
[target.x86_64-unknown-linux-musl]
linker = "x86_64-linux-musl-gcc"
[target.aarch64-unknown-linux-musl]
linker = "aarch64-linux-musl-gcc"
[target.x86_64-unknown-linux-gnu] - notneeded
linker = "x86_64-unknown-linux-gnu-gcc"
3. export TARGET_CC
x86_64:
export TARGET_CC=x86_64-linux-musl-gcc
for arm7:
export TARGET_CC=aarch64-linux-musl-gcc
4. compiling openssl
include the openssl crate:
openssl = { version = "0.10", features = ["vendored"] }
5. build for target
cargo build --target x86_64-unknown-linux-musl
cargo build --target aarch64-unknown-linux-musl
The first step is to determine which dependency is using openssl, which you can do with crate tree:
crate tree --target=x86_64-unknown-linux-musl -i openssl-sys
In my case this identified the rusoto_core crate as the one depending on it. Some crates can be compiled with feature flags to use alternate TLS libraries, making them easier to use than OpenSSL.
For example, Rusoto enables rustls like this in the Cargo.toml:
rusoto_core = {version = "0.42.0", default_features = false, features=["rustls"]}
rusoto_s3 = {version = "0.42.0", default_features = false, features=["rustls"]}
rusoto_sqs = {version = "0.42.0", default_features = false, features=["rustls"]}
In the Rusoto case, there is documentation for cross-compiling for use with AWS Lambda: https://rusoto.org/lambdas.html
Alternately, you may be able to provide cross-compiled OpenSSL to the compiler, but from what I understand this is more difficult and poorly documented at this time.

Cargo fails to build openssl [duplicate]

I tried to install the Iron framework for Rust on Mac OS X 10.11.2, but it failed when I run cargo build or cargo run on compiling openssl's stuff:
failed to run custom build command for `openssl-sys-extras v0.7.4`
Process didn't exit successfully: `/xxx/rust/hello/target/debug/build/openssl-sys-extras-413d6c73b37a590d/build-script-build` (exit code: 101)
--- stdout
TARGET = Some("x86_64-apple-darwin")
OPT_LEVEL = Some("0")
PROFILE = Some("debug")
TARGET = Some("x86_64-apple-darwin")
debug=true opt-level=0
HOST = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
HOST = Some("x86_64-apple-darwin")
CC_x86_64-apple-darwin = None
CC_x86_64_apple_darwin = None
HOST_CC = None
CC = None
HOST = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
HOST = Some("x86_64-apple-darwin")
CFLAGS_x86_64-apple-darwin = None
CFLAGS_x86_64_apple_darwin = None
HOST_CFLAGS = None
CFLAGS = None
running: "cc" "-O0" "-ffunction-sections" "-fdata-sections" "-g" "-m64" "-fPIC" "-o" "/xxx/rust/hello/target/debug/build/openssl-sys-extras-413d6c73b37a590d/out/src/openssl_shim.o" "-c" "src/openssl_shim.c"
ExitStatus(Code(1))
command did not execute successfully, got: exit code: 1
--- stderr
src/openssl_shim.c:1:10: fatal error: 'openssl/hmac.h' file not found
#include <openssl/hmac.h>
^
1 error generated.
thread '<main>' panicked at 'explicit panic', /xxx/.cargo/registry/src/github.com-0a35038f75765ae4/gcc-0.3.21/src/lib.rs:772
openssl version seems OK:
$ openssl version
OpenSSL 0.9.8zg 14 July 2015
I don't know what I have to do in order to make this installation work and give Iron a try.
As of rust-openssl version 0.8, Homebrew-installed OpenSSL libraries will be automatically detected by the crate, there is no need to set extra environment variables.
If you need to support a version prior to that or choose to not use Homebrew, read on.
This is a known issue (also this and this), but not one that the crate can fix.
The quick solution is to install OpenSSL with Homebrew and then explicitly point to the directories where OpenSSL is found by setting the OPENSSL_INCLUDE_DIR and OPENSSL_LIB_DIR environment variables:
OPENSSL_INCLUDE_DIR=/usr/local/Cellar/openssl/1.0.2e/include \
OPENSSL_LIB_DIR=/usr/local/Cellar/openssl/1.0.2e/lib \
cargo build
If you've already done one cargo build, you will need to run cargo clean first to clear our some stale cached information.
If you don't want to set this for every shell you open, add it to your shell initialization files (like ~/.bash_profile). You can make it a bit less brittle by not hard-coding the version number:
export OPENSSL_INCLUDE_DIR=$(brew --prefix openssl)/include
export OPENSSL_LIB_DIR=$(brew --prefix openssl)/lib
If you don't want to use Homebrew, follow the same process but using the appropriate path to your copy of OpenSSL.
The longer reason is well described by andrewtj:
OpenSSL doesn't have a stable ABI so for compatibility purposes Apple have maintained a fork that's compatible with one of the earlier ABIs. They deprecated OpenSSL in 10.7 and finally dropped the headers in 10.11 to push OS X app developers toward bundling their own OpenSSL or using their frameworks. The dylibs have been left around so apps that haven't been updated don't break. You can still link against them but you're opening yourself up to odd compatibility issues by doing so (unless you grab the headers from an earlier OS X release).
With Brew use like this:
brew install openssl
export OPENSSL_INCLUDE_DIR=`brew --prefix openssl`/include
export OPENSSL_LIB_DIR=`brew --prefix openssl`/lib
cargo clean
cargo build
If you have homebrew's openssl installed just add the following to your Cargo.toml:
[target.x86_64-apple-darwin.openssl-sys]
rustc-link-search = [ "/usr/local/opt/openssl/lib" ]
rustc-link-lib = [ "ssl", "crypto" ]
include = [ "/usr/local/opt/openssl/include" ]
and then cargo clean && cargo build. No breaking OS X by introducing an incompatible openssl into the library load paths, and no forgetting to set/unset environment variables when you want to build (or polluting your shell env when not working on Rust stuff). All in all a much happier and less infuriating approach.
I can't add this answer to my own question where it belongs (because it depends on homebrew), because Shepmaster decided it should be closed but I'll answer here and link to that question.
https://stackoverflow.com/a/39380733/1317564's answer for MacPorts:
sudo port install openssl
export OPENSSL_INCLUDE_DIR=/opt/local/include
export OPENSSL_LIB_DIR=/opt/local/lib
cargo clean
cargo build

Resources