Build OpenSSL from source

[sfackler]

Closes #580

[alexcrichton]

You may want to read the cflags from gcc-rs to pass here (instead of manually passing -fPIC/-m32)

[alexcrichton]

Could you be sure to include output.status in this output as well?

[alexcrichton]

👍

Perhaps openssl could dogfood this support itself? IIRC we build OpenSSL for ARM on CI

[metajack]

What is this waiting on?

[sfackler]

It doesn't work yet in cross compilation contexts and Windows, and I haven't had a chance to finish it.

[alexcrichton]

We discussed this a bit at the recent all-hands and some thoughts on this were:

• Downloading OpenSSL is still a bit of a pain, and maybe we can relieve the pressure on @sfackler by having others (e.g. the infra team for Rust) manage releases for an openssl-src crate? That way no one person (notably @sfackler) is on the hook for making releases when CVEs are released, and it should still be beneficial for making depending on this crate "pretty easy" in the sense that it still builds from source, the source is just automatically acquired.
• This feature could be off-by-default to only allow it in some situations (if necessary).

[alexcrichton]

I've started a repository for this at https://github.com/alexcrichton/openssl-src-rs. Right now I believe it's got the right logic for building for all "relevant" platforms for now, and there should be CI verifying that the build works and everything at least links correctly. Right now it's intended to be used as a build dependency, so during openssl-sys's fallback after failing to find a global installation it'd build one from source (in theory).

@sfackler and I talked at RustConf about the Windows situation as well. Unfortunately building OpenSSL requires perl to be installed, which while common enough on Unix is pretty rare on Windows. Note though that MinGW is probably ok here where it's easy enough to install perl as a build dependency, but on MSVC it's not quite as trivial.

We discussed in person the possibility of shipping binaries. In this way the MSVC platform would have prebuilt binaries ready-to-go which would be used by default instead of building from source. Upon further reflection, though, I'm not sure this is a great idea:

• We'd have to have at least crt-static/non-crt-static binaries, doubling the size of the CI and downloads here
• Being static libraries, I don't believe they're specific to a particular VS compiler. That is, I don't think MSVC guarantees a stable C ABI with the C runtime across revisions of Visual Studio, so the binaries are actually only valid for the visual studio version that produced them.

And that's a little unfortunate! I think I'd be tempted to, for now, advocate for perl as a dependency on Windows to build from source (probably with instructions of how to get it in the README) and go from there. If we can nail down the binary story we could always relax the dependency in the future!

@sfackler how's that sound?

[sfackler]

I'm a bit suspicious about the cross VS library compatibility issues - plenty of projects provide precompiled Windows libraries without too much trouble AFAIKT. Having to provide crt-static/non-crt-static i686/x86_64 does seem like a bit much though.

I do feel bad about requiring a Perl install but it seems like there isn't a great way to avoid that other than maybe vendoring Perl itself which seems a bit iffy.