Make sure openssl compiles with only one core

[aidanhs]

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. But we don't do a parallel make on openssl do we? 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, make will pass the flags downwards 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

[alexcrichton]

@bors: r+ p=10

Holy cow nice find! That'd do it...

[bors]

📌 Commit 367e907 has been approved by alexcrichton

[bors]

⌛ Testing commit 367e907 with merge 612847b...

[denji]

libressl is not reproduced?

[aidanhs]

@denji sorry, I'm not sure what you're asking - can you elaborate?

[denji]

@aidanhs my question: build libressl instead of openssl can solve the problem of parallel make?

[aidanhs]

@denji ah I see. To be honest, I don't know. I can't see anything in the git log for libressl that suggests they've done anything about it, so my instinctive answer is "no".

That said, openssl have put some effort in (here and here), so potentially upgrading to 1.1.0 might also fix our issue.

If we verify that this PR fixes the failure over a period of a few weeks, then we could consider an experiment to upgrade to openssl 1.1.0 with an eye kept out for future failures. For now this PR is probably the fix with the lowest risk (assuming it works!).

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 612847b to master...