Unable to build cc_proto_library targets because of missing google::protobuf symbols

[nolen777]

I'm unable to build cc_proto_library targets directly or use them in googletest unit tests, though oddly they do work when used in a cc_binary target.

Steps to reproduce:

1. Clone https://github.com/nolen777/grail-test.git
2. bazel build //src/main/protobuf:test_cc_proto

Result:

INFO: Analyzed target //src/main/protobuf:test_cc_proto (67 packages loaded, 2834 targets configured).
INFO: Found 1 target...
ERROR: /Users/dancrosby/CodingProjects/github/grail-test/src/main/protobuf/BUILD.bazel:3:14: Linking src/main/protobuf/libtest_proto.dylib failed: (Exit 1): cc_wrapper.sh failed: error executing command (from target //src/main/protobuf:test_proto) external/toolchains_llvm~0.10.3~llvm~llvm_toolchain/bin/cc_wrapper.sh @bazel-out/darwin_arm64-fastbuild/bin/src/main/protobuf/libtest_proto.dylib-2.params

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
ld: Undefined symbols:
  google::protobuf::UnknownFieldSet::ClearFallback(), referenced from:
      google::protobuf::UnknownFieldSet::Clear() in test.pb.pic.o
  google::protobuf::UnknownFieldSet::default_instance(), referenced from:
      grailtest::proto::TestProto::_InternalSerialize(unsigned char*, google::protobuf::io::EpsCopyOutputStream*) const in test.pb.pic.o
  google::protobuf::UnknownFieldSet::MergeFrom(google::protobuf::UnknownFieldSet const&), referenced from:
      void google::protobuf::internal::InternalMetadata::DoMergeFrom<google::protobuf::UnknownFieldSet>(google::protobuf::UnknownFieldSet const&) in test.pb.pic.o
  google::protobuf::io::EpsCopyOutputStream::EnsureSpaceFallback(unsigned char*), referenced from:
<snip>

My setup:
Apple M1 Ultra
macOS Ventura 13.6
Xcode 15.0
bazel 6.2.1

There's nothing in my ~/.bazelrc file, the only project .bazelrc settings are the ones recommended for bazel-toolchain.

Notes:
bazel run //src/main/cpp:main builds and runs just fine, even though it has a dep on the target that I can't build directly. This matches my experience in a larger project, where I can build and run the main executable but not the individual proto targets. More importantly, cc_test targets fail to build because of the cc_proto_library failures.

If I comment out build --incompatible_enable_cc_toolchain_resolution in .bazelrc, the cc_proto_library target builds correctly.

[nolen777]

I think the issue is unique to building dylibs, and that's why the binary itself builds and runs -- it never builds the dylib even though it depends on the target.

For my cc_test targets in the other project, I can work around the problem by putting linkstatic = True in all the cc_library targets that include cc_proto_library deps.

[siddharthab]

Thank you for reporting this error. I will look into this.

[nolen777]

One more data point: as far as I can tell, the default bazel toolchain does not build a dylib at all; here's the final section when I run bazel build -s --linkopt=-v --linkopt=-Wl,-v //src/main/protobuf:test_cc_proto without incompatible_enable_cc_toolchain_resolution:

SUBCOMMAND: # //src/main/protobuf:test_proto [action 'Linking src/main/protobuf/libtest_proto.a', configuration: 157bf142b79db60fba295de3df48155ad5c34b73f2d550d2fec810be9fe21602, execution platform: @local_config_platform//:host]
(cd /private/var/tmp/_bazel_dancrosby/f0d93c3f9e9ba2c50b7eea59373de0a3/execroot/_main && \
  exec env - \
    APPLE_SDK_PLATFORM=MacOSX \
    APPLE_SDK_VERSION_OVERRIDE=14.0 \
    PATH='/opt/homebrew/opt/[email protected]/bin:/opt/homebrew/Caskroom/miniconda/base/condabin:/usr/local/opt/ruby/bin:/Users/dancrosby/google-cloud-sdk/bin:/Users/dancrosby/Library/Python/3.9/bin:/usr/local/opt/gnu-sed/libexec/gnubin:/opt/homebrew/opt/grep/libexec/gnubin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/share/dotnet:/opt/X11/bin:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Applications/Xamarin Workbooks.app/Contents/SharedSupport/path-bin:/Users/dancrosby/bin:/Users/dancrosby/go/bin:/Users/dancrosby/Library/Application Support/Coursier/bin' \
    XCODE_VERSION_OVERRIDE=15.0.0.15A240d \
    ZERO_AR_DATE=1 \
  external/bazel_tools~cc_configure_extension~local_config_cc/libtool -D -no_warning_for_no_symbols -static -o bazel-out/darwin_arm64-fastbuild/bin/src/main/protobuf/libtest_proto.a bazel-out/darwin_arm64-fastbuild/bin/src/main/protobuf/_objs/test_proto/test.pb.o)
# Configuration: 157bf142b79db60fba295de3df48155ad5c34b73f2d550d2fec810be9fe21602
# Execution platform: @local_config_platform//:host
Target //src/main/protobuf:test_cc_proto up-to-date:
  bazel-bin/src/main/protobuf/test.pb.h
  bazel-bin/src/main/protobuf/test.pb.cc
  bazel-bin/src/main/protobuf/libtest_proto.a
INFO: Elapsed time: 12.046s, Critical Path: 4.46s
INFO: 194 processes: 2 internal, 192 darwin-sandbox.
INFO: Build completed successfully, 194 total actions

Note that no dylib is built (or is present in the resulting directory), and the libtool invocation includes -static.

[siddharthab]

This seems to be a regression from #189 and was not completely documented there. The fix for this (until Bazel 7 is released) will be to add --features=-supports_dynamic_linker to your project .bazelrc.

[siddharthab]

#230 is the best we can do at this moment.

[nolen777]

Confirming that --features=-supports_dynamic_linker also works -- thank you.