Auto merge of #41563 - aidanhs:aphs-fix-spurious-osx-openssl-failure,…

… r=alexcrichton

Make sure openssl compiles with only one core

This is (hopefully) a fix for the osx openssl spurious failure - #40417.

The intermittent failures and failing in different ways made me think of a race condition. But programs are parallel make safe right? [Not openssl](openssl/openssl#298). But we don't do a parallel make on openssl [do we](https://github.com/rust-lang/rust/blob/8c4f2c64c6759a82f143e23964a46a65c67509c9/src/bootstrap/native.rs#L309)? This confused me, except "Waiting for unfinished jobs" is present in the logs...which is evidence of a parallel make!

It turns out that when we invoke to top level target [in run.sh](https://github.com/rust-lang/rust/blob/036983201d4e9aeb5c5e56e47c305971972b2569/src/ci/run.sh#L75-L77), make will [pass the flags downwards](https://www.gnu.org/software/make/manual/html_node/Options_002fRecursion.html) in order to take advantage of parallelism in sub-makes. Of course, we don't want this in openssl! Override this by explicitly disabling parallelism on the command line.

I don't know why this hasn't happened on anything except OSX. Maybe Linux binutils check if the file is in use?

r? @alexcrichton

src/bootstrap/native.rs

@@ -306,7 +306,7 @@ pub fn openssl(build: &Build, target: &str) {
     println!("Configuring openssl for {}", target);
     build.run_quiet(&mut configure);
     println!("Building openssl for {}", target);
-    build.run_quiet(Command::new("make").current_dir(&obj));
+    build.run_quiet(Command::new("make").arg("-j1").current_dir(&obj));
     println!("Installing openssl for {}", target);
     build.run_quiet(Command::new("make").arg("install").current_dir(&obj));