commit | 505c2c6277835b1689969e01edd26a1fe03f38b4 | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Sun Sep 22 14:54:36 2024 -0400 |
committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Sep 23 20:05:58 2024 +0000 |
tree | 8985f0d3cc01a1ccddb45fac0934225dbe720248 | |
parent | a4eb021cfa159497648eab66c4fece99c59bed0c [diff] |
Work around a workaround of a workaround of a Bazel bug This fixes an issue where :ssl_test in the Bazel build ran no tests. (The CMake build was fine.) Bazel has no way to handle C and C++ sources need different flags (https://github.com/bazelbuild/bazel/issues/22041), so our Bazel rules transparently split mixed C/C++ targets in two. Bazel silently turns all static libraries into shared libraries for tests. This means that, even if we set linkstatic = True on the split-out library, the two halves don't end up in the same shared object. This is because if A(test) -> B(lib) -> C(lib) and C is linkstatic, C is statically linked into A, not B. This is probably to avoid diamond dependency issues. From what I can tell, there is no clean way to say "B can be made into a shared library but please statically link C into it, because C will never be referenced except by way of B". (This means our use of linkshared is wrong. The next CL will try to redo that.) This Bazel behavior does not recognize that static and shared libraries have very, very different symbol handling. In particular, our assembly files needed to be in the same shared object as OPENSSL_ia32cap_P, so all this required another workaround in https://boringssl-review.googlesource.com/c/boringssl/+/70690 This, in turn, triggered this latest issue: GoogleTest relies on static initializers of individual object files to register tests. This does not work with linker dead code elimination and needs --whole-archive, or alwayslink in Bazel parlance. The most recent Bazel workaround required the C++ sources be the ones that were extracted, so they lost the --whole-archive behavior. As a result, :ssl_test silently ran no tests! Work around this latest Bazel-induced problem by setting alwayslink on cc_test helpers. All this would go away if Bazel just fixed https://github.com/bazelbuild/bazel/issues/22041 (We can probably revert https://boringssl-review.googlesource.com/c/boringssl/+/70690 now, but either way we should probably set alwayslink=True on the helpers so that the build is not sensitive to which were extracted.) Change-Id: I10745e1bcfe91ac929f154e66093b29723efc576 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/71507 Reviewed-by: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: