> Note: this mail follows the discussion on github started here:
> https://github.com/openssl/openssl/pull/5742#discussion_r176919954
> That discussion started as a simple side note, but I should probably
> have known better... it ends up derailing a PR that shouldn't really
> be affected, so I'm
> appro> We already touched this in Windows context, one option (more suitable
> in
> appro> my mind) is toolchain-specific *rules*. I.e. instead of trying to fit
> appro> cube into circular hole, just make square hole on the side. For example
> appro> *if* target has ldonly attribute, just emit l
>> Note: this mail follows the discussion on github started here:
>> https://github.com/openssl/openssl/pull/5742#discussion_r176919954
In the light of the new evidence presented in
https://github.com/openssl/openssl/pull/5745 one can argue in favour of
splitting -pthread flag to cppflags and ldfl
In message <7e8cc500-3739-e32a-e036-4c3eb8f28...@openssl.org> on Sun, 25 Mar
2018 15:20:54 +0200, Andy Polyakov said:
appro> > My spin on it goes in a different direction. It's true that we
appro> > *currently* pass cflags to all stages. I would argue, though, that
appro> > this is mostly beca
Note: this mail follows the discussion on github started here:
https://github.com/openssl/openssl/pull/5742#discussion_r176919954
That discussion started as a simple side note, but I should probably
have known better... it ends up derailing a PR that shouldn't really
be affected, so I'm bringing t
