Skip to content

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

@phenylshima

Description

@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)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions