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>
1 file changed
tree: 8985f0d3cc01a1ccddb45fac0934225dbe720248
  1. .bcr/
  2. .github/
  3. cmake/
  4. crypto/
  5. decrepit/
  6. docs/
  7. fuzz/
  8. gen/
  9. include/
  10. pki/
  11. rust/
  12. ssl/
  13. third_party/
  14. tool/
  15. util/
  16. .bazelignore
  17. .bazelrc
  18. .clang-format
  19. .gitignore
  20. API-CONVENTIONS.md
  21. BREAKING-CHANGES.md
  22. BUILD.bazel
  23. build.json
  24. BUILDING.md
  25. CMakeLists.txt
  26. codereview.settings
  27. CONTRIBUTING.md
  28. FUZZING.md
  29. go.mod
  30. go.sum
  31. INCORPORATING.md
  32. LICENSE
  33. MODULE.bazel
  34. MODULE.bazel.lock
  35. PORTING.md
  36. PrivacyInfo.xcprivacy
  37. README.md
  38. SANDBOXING.md
  39. STYLE.md
README.md

BoringSSL

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: