A fix for this issue has been included in [Bazel 6.4.0 RC1](https://releases.bazel.build/6.4.0/rc1/index.html). Please test out the release candidate and report any issues as soon as possible. Thanks! Fix is from the PR: https://github.com/bazelbuild/bazel/pull/19534 I confirmed that this issue is fixed in `6.4.0 rc1`.
Thank you!
Backport bugfixes for "cc_proto_library not linked to target" to 6.x
### 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.

```patch
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
    ```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
    ```protobuf
    syntax = "proto2";

    package mozc.commands;

    message Config {
    }

    ```
3. Add test.cc
    ```c++
    #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)
```
src/main/starlark/builtins_bzl/common/cc/cc_proto_library.bzl
src/main/starlark/builtins_bzl/common/cc/cc_proto_library.bzl
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 55036600f8ebbf..fa7f896264c386 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],
 )
