Compile OpenSSL from source on OSX #3332
Conversation
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
|
I’ve seen Travis fail with "Illegal instruction: 4" on OS X on the Nigthly channel, but OpenSSL is not involved. In fact, even |
|
@SimonSapin unfortunately I haven't confirmed that the illegal instruction is specifically related to OpenSSL, but it's the biggest thing that changed that'd cause me to suspect it. OpenSSL is actually always related I believe because we initialize the various libraries (libgit2, libssh2, openssl) I believe on startup no matter the command. So in that sense I think there's at least a vector for OpenSSL to get involved? Obviously a stack trace would be best but unfortunately I don't know how to get one out of Travis. |
|
Oh, sorry, you mean cargo itself using OpenSSL. I was thinking of cargo building the rust-openssl crate. |
|
Oh right yeah Cargo's linking to OpenSSL, but the way we do that changed very recently, and that's what I think the bug is (pulling in bad binaries). Another reason I suspect this is at fault is that locally Cargo works just fine for me, but I also likely have a more recent Mac with a newer CPU than what Travis is running (presumably) |
I'm seeing a bunch of weird illegal instructions on OSX nightlies for Cargo. My guess is that they're all related to OpenSSL linking. Right now we're linking from Homebrew but I have a sneaking suspicion that it compiles with `-march=native` rather than what we'd like as a portable binary. To work around this compile OpenSSL ourselves and link it that way. Note that I believe this won't bring in the certificate trust store of OpenSSL on OSX (or at least not the right one from the keychain). We shouldn't need that, however, as OpenSSL is just used as the cryptographic primitives in libssh2 and Cargo itself. So in that sense we shouldn't need it for actually SSL at all.
alexcrichton
force-pushed
the
build-openssl
branch
from
4c45c7b to
8ab8595
Compare
|
@bors: r+ |
|
📌 Commit 8ab8595 has been approved by |
Compile OpenSSL from source on OSX I'm seeing a bunch of weird illegal instructions on OSX nightlies for Cargo. My guess is that they're all related to OpenSSL linking. Right now we're linking from Homebrew but I have a sneaking suspicion that it compiles with `-march=native` rather than what we'd like as a portable binary. To work around this compile OpenSSL ourselves and link it that way. Note that I believe this won't bring in the certificate trust store of OpenSSL on OSX (or at least not the right one from the keychain). We shouldn't need that, however, as OpenSSL is just used as the cryptographic primitives in libssh2 and Cargo itself. So in that sense we shouldn't need it for actually SSL at all.
|
☀️ Test successful - cargo-cross-linux, cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64 |
Backporting fixes to 1.14.0 This is a backport of the following PRs to fix the actual issue, rust-lang/rust#37969. * #3311 - first attempt to fix OpenSSL linkage on OSX * #3315 - second attempt to fix linkage * #3325 - fix a flaky test causing lots of CI problems * #3332 - actual fix for OpenSSL linkage on OSX * #3345 - first PR for automation changes * #3350 - second PR for automation changes * #3326 - update git2 to support netbsd * #3331 - update git2 to fix segfaults in tests * #3342 - update git2 to fix cert paths
I'm seeing a bunch of weird illegal instructions on OSX nightlies for
Cargo. My guess is that they're all related to OpenSSL linking. Right
now we're linking from Homebrew but I have a sneaking suspicion that it
compiles with
-march=nativerather than what we'd like as a portablebinary. To work around this compile OpenSSL ourselves and link it that
way.
Note that I believe this won't bring in the certificate trust store of
OpenSSL on OSX (or at least not the right one from the keychain). We
shouldn't need that, however, as OpenSSL is just used as the
cryptographic primitives in libssh2 and Cargo itself. So in that sense
we shouldn't need it for actually SSL at all.