Obscure build failure on Windows after Bazel commit f6c4e624dc89ee0600b418eeea7108b6ed5c9708

[Philipp Stephani]

Hi,

I wasn't able to provide a truly minimal example for the following behavior, and I don't know where exactly the problem is (Bazel or my own code), so I figured I should first start a discussion before trying to open a bug against Bazel. To reproduce the issue, clone the repository https://github.com/phst/rules_elisp (HEAD commit at the time of this writing is 36e79c5ba5b7d3e2543e78cbdc0631b8170d9922) on some Windows machine, and build //elisp/proto:all using any Bazel version that contains the commit f6c4e624dc89ee0600b418eeea7108b6ed5c9708, e.g. using Bazelisk and USE_BAZEL_VERSION with that commit hash, or 'rolling', or any prerelease version starting with 6.0.0-pre.20220216.3:

SET USE_BAZEL_VERSION=f6c4e624dc89ee0600b418eeea7108b6ed5c9708
bazelisk build //elisp/proto:all

Depending on the specifics of the build machine, you might want to pass --noworkspace_rc – the workspace's .bazelrc is optimized for the GitHub managed runner, but other OS versions might require different flags (especially Pytype tends to be an issue, but is not needed here).

This will result in an error like

ERROR: C:/users/p/_bazel_p/7fb4vwtb/external/upb/BUILD:94:11: Linking external/upb/upb_ccd612482e.dll failed: (Exit 1120): link.exe failed: error executing command (from target @upb//:upb) C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\link.exe @bazel-out/x64_windows-fastbuild/bin/external/upb/upb_ccd612482e.dll-2.params
Creating library bazel-out/x64_windows-fastbuild/bin/external/upb/upb.if.lib and object bazel-out/x64_windows-fastbuild/bin/external/upb/upb.if.exp
decode.obj : error LNK2019: unresolved external symbol utf8_naive referenced in function utf8_range2
bazel-out\x64_windows-fastbuild\bin\external\upb\upb_ccd612482e.dll : fatal error LNK1120: 1 unresolved externals

Here the problem appears to be that Bazel tries to build intermediary DLLs, which doesn't work well on Windows because DLLs don't export any symbols by default. There's some code in Bazel to not build these DLLs (instead only building static libraries), but for some reason I don't understand yet the code doesn't work in this case under newer Bazel versions. I manually bisected the problem down to Bazel commit f6c4e624dc89ee0600b418eeea7108b6ed5c9708 ("Changes necessary for Starlark cc_library"), which does look related (it touches areas of the codebase that are closely related to building C++ libraries), but I don't know how exactly.

Thanks,
Philipp

[p.ste...@gmail.com]

I managed to add a workaround for this: https://github.com/phst/rules_elisp/commit/bf934db750f9362279c1a57badcaaeaeb3f92177

Also filed as Bazel bug: https://github.com/bazelbuild/bazel/issues/15735