Closed fpagliughi closed 2 years ago
I don't have a Windows machine myself, but can use one at the office. So will have a look later this week...
Last week was a bad week... I'll hopefully have a better week this week, so keep you posted.
In my case, it was also needed to install perl to compile an application
Yes, thanks @rkudryashov. Finally thought to RTFM! Sure enough it mentions that:
The [vendored] build process requires a C compiler, perl, and make.
in the Rust OpenSSL docs
I should probably summarize those docs in the README here. Then I can probably get rid of most of the SSL/TLS code in build.rs
and just let openssl-sys
do its thing. The only exception I can think of right now, though, would be to add back in the check for the library in the usual manually-installed locations on Windows, like C:\OpenSSL-Win64
if it's not found automatically.
I think there are a whole list of usage constraints, but overall, with a few guidelines and some additions like #113, things can generally be made to work. This probably needs a few additions to the README, but overall, openssl-sys
has been a big improvement.
So far, using
openssl-sys
has been great on Linux, especially when cross-compiling; now we don't have to try to find a cross-compiled version of OpenSSL for the target. The build handles it.But it seems that
openssl-sys
made things slightly worse on Window.openssl-sys
crate doesn't find the library in the standard install locations, and now ourbuild.rs
can help with that.I'm wondering if we should avoid
openssl-sys
on Windows and letbuild.rs
look for it in the standard locations? Or leave it as-is and tell Windows users they must always setOPENSSL_DIR
?Or am I doing something wrong on Windows?!?
@svanharmelen and thoughts?
When attempting to build for Window x86_64 using MSVC, the vendored openssl-sys produces the following error:
When attempting a non-vendored build with openssl-sys, if OPENSSL_DIR is not set