Externals boringssl target fails to build on Windows

[wrowe]

Building on windows, the boringssl library dependency is broken, because it attempts to build both a static and dynamic lib. The dynamic lib built is not desired, and actually not functional. The error is;

ERROR: C:/_eb/external/boringssl/BUILD:130:1: output 'external/boringssl/crypto.if.lib' was not created
ERROR: C:/_eb/external/boringssl/BUILD:130:1: not all outputs were created or valid
ERROR: C:/_eb/external/envoy/bazel/foreign_cc/BUILD:67:1 not all outputs were created or valid

In bazel-bin/external/boringssl/, the build generates;

_objs
crypto.dll
crypto.dll-2.params
crypto.lib
crypto.lib-2.params
crypto.pdb
ssl.dll-2.params
ssl.lib
ssl.lib-2.params

The resulting crypto.dll has no export symbols, all of the boringssl externs are used only for static binding (in linux terms, these are non-pic objects.) As documented on msdn about link.exe, the /implib:crypto.if.lib will never be created when there are no exported symbols. The resulting (desired) crypto.lib is the complete, static library. ssl.dll cannot be created because it requires the missing crypto.if.lib to bind to crypto.dll, which was an invalid shared object library.

We should not be attempting to build dynamic libraries, emit .dll files or their corresponding .if.lib export binding libs, but it is not clear how to suppress this either within envoy's bazel/ logic or within boringssl itself.

@irengrig or @lizan would you have any clues?

[alyssawilk]

also @davidben in case he has ideas offhand, though it's likely Envoy-specific

[davidben]

I'm assuming this is using the master-with-bazel branch, rather than some Envoy-specific build? I don't know anything about bazel.

@agl may be able to help here, though I don't see anything in our top-level BUILD file that expresses an opinion on shared vs static libraries.

[wrowe]

In envoy, we are building "static", I'd expect bazel would carry that preference to the externals
components that are drawn in. It doesn't appear this is the case.

Is there a reason for using the fork-for-bazel, and not localizing an envoy copy
of bazel/externals/boringssl.BUILD? We could then override with a preference for static-only libs.
See https://docs.bazel.build/versions/master/be/c-cpp.html#cc_library.linkstatic

I think this simply needs to be toggled, but it's not clear whether we would want our own fork
of boringssl.BUILD rules (and perhaps consume master rather than an envoy fork?) or would we
patch BUILD from boringssl, or is there another way to force such an override of an external package?

[wrowe]

This is the flavor we are testing (after encountering the same on envoy master's older tag point).
Confirming this is the master-with-bazel branch.

    boringssl = dict(
        sha256 = "c209aeb8ead27011aaec35e7978b824aa04755483932b269233613f7b0273aba",
        strip_prefix = "boringssl-0131fdd1b2e5562109ec74515ee6f5531d881322",
        # To update BoringSSL, which tracks Chromium releases:
        # 1. Open https://omahaproxy.appspot.com/ and note <current_version> of linux/beta release.
        # 2. Open https://chromium.googlesource.com/chromium/src/+/refs/tags/<current_version>/DEPS and note
        # 3. Find a commit in BoringSSL's "master-with-bazel" branch that merges <boringssl_revision>.
        #
        # chromium-77.0.3865.35 (BETA)
        urls = ["https://github.com/google/boringssl/archive/0131fdd1b2e5562109ec74515ee6f5531d881322.tar.gz
    ),

[lizan]

@wrowe by default bazel allows library to be both static and dynamic, if your build targets are all using static library (i.e. binary target with linkstatic=1) then it won't bother with dynamic library artifacts. The issue you're seeing from foreign_cc is because curl is trying to pull both: https://github.com/envoyproxy/envoy/blob/master/bazel/foreign_cc/BUILD#L106, if you comment out this line it shouldn't block you anymore.

[wrowe]

Thanks for the explanation, lizan. This isn't envoy-specific, it's a basic flaw in how the boringssl BUILD stub was coded (a static library has no exports.) We have this solved now with PR 8280 (merged) for the static builds. There is more to do for their bazel schema, but no remaining issues here at envoy.

[agl]

(p.s., if the BoringSSL BUILD is busted (which is totally possible), and you can tell us what's wrong, we can change it. It ultimately comes from here and here.)

[wrowe]

The associated PR was closed Stale;

#8754

This remains an open issue, given this set of bazel elections;
build --features=fully_static_link
build --features=static_link_msvcrt
build --dynamic_mode=off

It doesn't seem we should have to force-override the linkstatic option to the boringssl component, as illustrated in the PR, but we do on Windows. This would likely break the OS/X build of Envoy since that build is entirely dynamic, from my understanding, so the PR cannot be adopted as-is.

Bazel expertise requested.

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[wrowe]

Hi @agl see my comment of January 6. I really don't have a good solution upstream to coerce BoringSSL bazel build to honor the flags I identified.