Backport bugfixes for "cc_proto_library not linked to target" to 6.x

[phenylshima]

Description of the bug:

Related to: #17091, #19056 , 590ee17

Similar to #19056, objects from protocol buffer are not linked properly after upgrading from 6.2.1 to 6.3.2,.
This seems to have been fixed in 590ee17, but the fix is not included in release-6.4.0 branch yet.

When a shared object is generated with bazel, some of the symbols from protobuf are not linked.

> nm -C -D bazel-bin/libtest.so
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
00000000000009c9 T test()
                 U mozc::commands::Config::Config(google::protobuf::Arena*, bool)
0000000000000a40 W mozc::commands::Config::Config()
0000000000000a40 W mozc::commands::Config::Config()
0000000000000a1a W mozc::commands::Config::~Config()
00000000000009ec W mozc::commands::Config::~Config()
00000000000009ec W mozc::commands::Config::~Config()
                 U google::protobuf::internal::ZeroFieldsBase::~ZeroFieldsBase()
                 U std::ios_base_library_init()@GLIBCXX_3.4.32
                 U vtable for mozc::commands::Config
                 U operator delete(void*)@GLIBCXX_3.4
0000000000002008 D __bss_start
                 w __cxa_finalize@GLIBC_2.2.5
                 w __gmon_start__
0000000000002008 D _edata
0000000000002009 D _end

Applying the following patch seems to fix the issue.

diff --git a/src/main/starlark/builtins_bzl/common/cc/cc_proto_library.bzl b/src/main/starlark/builtins_bzl/common/cc/cc_proto_library.bzl
index 55036600f8..fa7f896264 100644
--- a/src/main/starlark/builtins_bzl/common/cc/cc_proto_library.bzl
+++ b/src/main/starlark/builtins_bzl/common/cc/cc_proto_library.bzl
@@ -282,4 +282,5 @@ cc_proto_library = rule(
             allow_files = False,
         ),
     },
+    provides = [CcInfo],
 )

Which category does this issue belong to?

C++/Objective-C Rules

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

1. Add BUILD.bazel

   proto_library(
       name = "commands_proto",
       srcs = [
           "commands.proto",
       ],
       deps = [],
   )
   
   cc_proto_library(
       name = "commands_cc_proto",
       deps = [":commands_proto"],
   )
   
   cc_library(
       name = "test_lib",
       srcs = ["test.cc"],
       deps = [
           ":commands_cc_proto",
       ],
   )
   
   cc_shared_library(
       name = "test",
       roots = ["test_lib"],
   )

2. Add commands.proto

   syntax = "proto2";
   
   package mozc.commands;
   
   message Config {
   }
   

3. Add test.cc

   #include "commands.pb.h"
   
   void test(void) {
     mozc::commands::Config b;
   }
   

4. Build
   bazel build //:test --experimental_cc_shared_library
5. Check the generated shared library with nm
   nm -C -D bazel-bin/libtest.so

Which operating system are you running Bazel on?

Linux 6.1.49-1-MANJARO #1 SMP PREEMPT_DYNAMIC Sun Aug 27 23:08:04 UTC 2023 x86_64 GNU/Linux

What is the output of bazel info release?

release 6.3.2

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

No response

Have you found anything relevant by searching the web?

590ee17 may have fixed this issue, but I could not confirm it on master branch due to an unrelated error.

Any other information, logs, or outputs that you want to share?

Bazel 6.3.2 generates following result:

                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
00000000000009c9 T test()
                 U mozc::commands::Config::Config(google::protobuf::Arena*, bool)
0000000000000a40 W mozc::commands::Config::Config()
0000000000000a40 W mozc::commands::Config::Config()
0000000000000a1a W mozc::commands::Config::~Config()
00000000000009ec W mozc::commands::Config::~Config()
00000000000009ec W mozc::commands::Config::~Config()
                 U google::protobuf::internal::ZeroFieldsBase::~ZeroFieldsBase()
                 U std::ios_base_library_init()@GLIBCXX_3.4.32
                 U vtable for mozc::commands::Config
                 U operator delete(void*)@GLIBCXX_3.4
0000000000002008 D __bss_start
                 w __cxa_finalize@GLIBC_2.2.5
                 w __gmon_start__
0000000000002008 D _edata
0000000000002009 D _end

Bazel 6.2.1 generates following result:

                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
                 U _Unwind_Resume@GCC_3.0
0000000000004f86 W descriptor_table_commands_2eproto_getter()
0000000000004ee9 T test()
00000000000062e0 R TableStruct_commands_2eproto::offsets
00000000000058ba W mozc::commands::ConfigDefaultTypeInternal::~ConfigDefaultTypeInternal()
00000000000058ba W mozc::commands::ConfigDefaultTypeInternal::~ConfigDefaultTypeInternal()
0000000000009020 D mozc::commands::_Config_default_instance_
0000000000008970 D mozc::commands::Config::_class_data_
0000000000004f94 T mozc::commands::Config::Config(google::protobuf::Arena*, bool)
0000000000004fd6 T mozc::commands::Config::Config(mozc::commands::Config const&)
0000000000004f60 W mozc::commands::Config::Config()
0000000000004f94 T mozc::commands::Config::Config(google::protobuf::Arena*, bool)
0000000000004fd6 T mozc::commands::Config::Config(mozc::commands::Config const&)
0000000000004f60 W mozc::commands::Config::Config()
0000000000004f3a W mozc::commands::Config::~Config()
0000000000004f0c W mozc::commands::Config::~Config()
0000000000004f0c W mozc::commands::Config::~Config()
0000000000005aa8 W mozc::commands::Config* google::protobuf::MessageLite::CreateMaybeMessage<mozc::commands::Config>(google::protobuf::Arena*)
(reducted as the output is long)

[iancha1992]

A fix for this issue has been included in Bazel 6.4.0 RC1. Please test out the release candidate and report any issues as soon as possible. Thanks!

[iancha1992]

Fix is from the PR: #19534

[phenylshima]

I confirmed that this issue is fixed in 6.4.0 rc1.
Thank you!