Fix building with latest BoringSSL #2230
Conversation
|
Looks like the i686 build needs to be updated with |
|
Ah fun. @botovq was trying to convince me earlier that BoringSSL's cmake build should automatically set that. I liked that making the caller do it helped surface the issue and make them need to opt in that "yes, we are okay assuming sse2 support". But now that it's been a while and come up twice, yeah maybe we should just do it automatically now. |
|
That works for me.
…On Wed, May 1, 2024 at 9:33 PM David Benjamin ***@***.***> wrote:
Ah fun. @botovq <https://github.com/botovq> was trying to convince me
earlier that BoringSSL's cmake build should automatically set that. I liked
that making the caller do it helped surface the issue and make them need to
opt in that "yes, we are okay assuming sse2 support". But now that it's
been a while and come up twice, yeah maybe we should just do it
automatically now.
—
Reply to this email directly, view it on GitHub
<#2230 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAGBDV4WEF6RPSRBTMFWDZAGJUZAVCNFSM6AAAAABHCJNSEOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBZGM4DEMRSHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
All that is necessary for evil to succeed is for good people to do nothing.
|
|
Ended up setting it in CI because it (looked like) the place to update was very easy. Also given rust-lang/rust#82435, you all probably should be setting it across all OpenSSLs anyway. If your Rust code believes in SSE2, no sense denying your CI the extra registers on the C half! |
|
Hmm, CI seems to now be upset about |
|
latest rust got more aggressive about dead code warnings. #2234 should fix |
|
Ok, you should be good to rebase. |
This required two fixes. First, test_verify_param_set_depth_fails_verification needed to be updated. The history here is that OpenSSL 1.1.0 made a backwards-incompatible change to the semantics of the depth limit. Ideally, rust-openssl would have documented the semantics of its own APIs and normalized the behavior, but it instead silently picked up the semantics change. BoringSSL aligned with OpenSSL's new behavior in b251d813ec615e7ef01d82073f94960eb13b1e0a, but since then rust-openssl has codified the old behavior in tests. We need to update some cfgs to reflect this. Second, BoringSSL requires a C++ runtime (we have required a C++ compiler for a long time). This reveals a problem in Cargo's dependency management strategy for externally-built static libraries. Work around this by making some guesses about what library to link in, but see the comment for why this is unsafe. This unsafety appears to be inherent to Cargo and the choice of having Cargo drive cross-language builds, rather than providing hooks for an integrated build system.
Newer BoringSSL requires SSE2 on 32-bit x86, but I opted to apply it to all the OpenSSLs that CI builds. This allows the compiler to vectorize random bits of the library, so hopefully it'll run faster on CI. Especially with 32-bit x86 being so register-poor. Additionally, Rust's definition of i686 already assumes SSE2 (see rust-lang/rust#82435), so there's no sense in pretending to test pre-SSE2 targets.
|
Rebased! |
This required two fixes. First, test_verify_param_set_depth_fails_verification needed to be updated. The history here is that OpenSSL 1.1.0 made a backwards-incompatible change to the semantics of the depth limit. Ideally, rust-openssl would have documented the semantics of its own APIs and normalized the behavior, but it instead silently picked up the semantics change.
BoringSSL aligned with OpenSSL's new behavior in
b251d813ec615e7ef01d82073f94960eb13b1e0a, but since then rust-openssl has codified the old behavior in tests. We need to update some cfgs to reflect this.
Second, BoringSSL requires a C++ runtime (we have required a C++ compiler for a long time). This reveals a problem in Cargo's dependency management strategy for externally-built static libraries. Work around this by making some guesses about what library to link in, but see the comment for why this is unsafe. This unsafety appears to be inherent to Cargo and the choice of having Cargo drive cross-language builds, rather than providing hooks for an integrated build system.