On Windows, failed to run custom build command

[LeMoussel]

For Windows (MSVC ABI) 32-bit, On cargo build:

Compiling winapi-build v0.1.1
Compiling libc v0.2.15
Compiling gdi32-sys v0.2.0
Compiling winapi v0.2.8
Compiling user32-sys v0.2.0
Compiling pkg-config v0.3.8
Compiling openssl-sys v0.7.16
Compiling gcc v0.3.32
Compiling openssl-sys-extras v0.7.14
error: failed to run custom build command for openssl-sys-extras v0.7.14
Process didn't exit successfully: C:\RUST Project\test_hyper\target\debug\build\openssl-sys-extras-0ba92f782c10427a\build-script-build (exit code: 101)

C:\RUST Project\test_hyper>rustc --version
rustc 1.10.0 (cfcb716cf 2016-07-03)
C:\RUST Project\test_hyper>cargo --version
cargo 0.11.0-nightly (259324c 2016-05-20)

[sfackler]

Did you follow the instructions in the README to point the crate to OpenSSL's headers?

Make sure you "cargo clean" after setting it up.

[LeMoussel]

Yes I create an environment variable OPENSSL_INCLUDE_DIR with the value C:\OpenSSL\include and another variable OPENSSL_LIB_DIR with the value C:\OpenSSL\lib (https://github.com/sfackler/rust-openssl#windows) with the SET command. Same error (exit code: 101).

I dowload

• Runtime binaries: openssl-1.0.2h-i386-win32.zip, (http://indy.fulgan.com/SSL/) and place the DLL files from runtime binary into C:\OpenSSL\lib
• Include folder into C:\OpenSSL\include, from GitHub, (https://github.com/openssl/openssl). Include folder is empty in Runtime binaries.

Rem : No errors under msys2.

[wfraser]

I have a similar problem, with MSVC 64-bit. According to openssl/build.rs, you need to set DEP_OPENSSL_INCLUDE, in addition to OPENSSL_INCLUDE_DIR, so the README is incomplete... That got me past the initial part of the build. But then I hit a link error, where it tries to link with ssl32.lib, which is wrong, it needs to be ssleay32.lib because that's what's in the Win32 OpenSSL distribution. openssl-sys/build.rs uses that correctly if mingw32 is found in the user's PATH, but not otherwise, which in any case seems very strange to me. Why probe PATH and not use the target specification?

[sfackler]

DEP_OPENSSL_INCLUDE is set by openssl-sys's build script. It shouldn't be modified manually.

[wfraser]

Huh, not sure why it got me farther in the build.

Actually, looking at the openssl-sys/build.rs, its linking logic is even more weird, it uses the wrong lib names if any lib path is explicitly specified...

[wfraser]

(I think my issue is different from LeMoussel's, but for posterity, I fixed mine by setting OPENSSL_LIBS=ssleay32:libeay32)

[sfackler]

The resolution of what libraries are named on windows is a huge ad-hoc mess. I'm not actually totally sure what the right behavior is there.

[lilith]

If all the values can be passed via env vars, then I can use Cargo.io to fetch/build/produce the correct values for the build/platform.

[dudymas]

I was unable to get static linking to respect the OPENSSL_LIBS env variable... as such, I literally used copy libeay32.lib eay32.lib and so on... changing the filenames was the final part of this desperate build environment fandango. I'm actually having a hard time proving this is broken anymore

Thanks to everyone here sharing their own solutions. I'm okay in the short term with filename tweaks... but I'm assuming this will later need to make sure:

1. that ssl32.lib can be configured by ENV
2. that eay32.lib can be configured by ENV

frankly, I'm guessing it has to be that way because no one truly owns openssl builds on windows... it's just a charity and these are the breadcrumbs.

[sfackler]

The 0.9 release has heavily overhauled the library lookup process.