-
Notifications
You must be signed in to change notification settings - Fork 4.4k
Backport bugfixes for "cc_proto_library not linked to target" to 6.x #19450
Copy link
Copy link
Closed
Labels
Description
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.
- 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"], )
- Add commands.proto
syntax = "proto2"; package mozc.commands; message Config { }
- Add test.cc
#include "commands.pb.h" void test(void) { mozc::commands::Config b; }
- Build
bazel build //:test --experimental_cc_shared_library - 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)
Reactions are currently unavailable