31.0: protoc linking fails due to missing `upb_AllExts` symbols

[mtelka]

What version of protobuf and what language are you using? Version: 31.0 Language: N/A

What operating system (Linux, Windows, ...) and version? OpenIndiana Hipster

What runtime / compiler are you using (e.g., python version or gcc version) GCC 14

What did you do? I'm trying to compile protobuf 31.0 on OpenIndiana.

What did you expect to see The compilation complete successfully (as it did with versions 24.4, 29.3, 30.1, 30.2).

What did you see instead?

[ 50%] Linking CXX executable protoc
Undefined                       first referenced
 symbol                             in file
__stop_linkarr_upb_AllExts          libprotoc.so.31.0.0  (symbol scope specifies local binding)
__start_linkarr_upb_AllExts         libprotoc.so.31.0.0  (symbol scope specifies local binding)
ld: fatal: symbol referencing errors. No output written to protoc-31.0.0
collect2: error: ld returned 1 exit status

Anything else we should know about your project / environment This is with native illumos (Solaris) linker, not GNU ld.

[mtelka]

I bisected the issue to the move of the upb minitable code generator into protoc. Particularly, the following set of changes is causing the problem:

dce6b0f14bd264d2fc9d92a7f5005d7a87b80b02 b90cc56e5dd5064e8693a1c9ee9981930e330927 7229ef1b4f0f975036b140fe71c76d25feff4918

[acozzette]

We are actually getting ready to move the minitable code generator back out of protoc, so I think that should fix the problem. Unfortunately, though, that probably won't happen until the 32.0 release scheduled for July.

[mtelka]

The 32.0 timeframe is okay and fully acceptable. We will simply skip the 31.x line. Thank you.

[acozzette]

Actually I realized that this will not automatically be fixed in 32.0. We're moving the upb minitable generator out of protoc but introducing a new upb dependency in the Rust generator, so the problematic symbols are still going to be there in protoc.

It seems to me like the Illumos linker probably doesn't support linker arrays or at least doesn't support them the way we are currently using them.

Is there a macro we could check to determine if we're on an Illumos build so that we could just disable our use of linker arrays? We don't use them for anything in protoc, so that could be an easy way to fix this build.

[scpeters]

We are actually getting ready to move the minitable code generator back out of protoc, so I think that should fix the problem. Unfortunately, though, that probably won't happen until the 32.0 release scheduled for July.

it looks like this was done in https://github.com/protocolbuffers/protobuf/pull/21886

Actually I realized that this will not automatically be fixed in 32.0. We're moving the upb minitable generator out of protoc but introducing a new upb dependency in the Rust generator, so the problematic symbols are still going to be there in protoc.

but it sounds like this change may not fix the problem

[mtelka]

Is there a macro we could check to determine if we're on an Illumos build so that we could just disable our use of linker arrays? We don't use them for anything in protoc, so that could be an easy way to fix this build.

You can check for __illumos__ (see https://www.illumos.org/issues/13726 for more info).

[guw]

I am hitting a similar (the same?) issue linking protobuf 33.1 in Bazel.

ld.lld: error: undefined symbol: __stop_linkarr_upb_AllExts
>>> referenced by extension_registry.c
>>>               extension_registry.o:(upb_ExtensionRegistry_AddAllLinkedExtensions) in archive bazel-out/aarch64-opt-exec-ST-12dfad941fb6/bin/external/protobuf+/upb/mini_table/libmini_table.a
>>> referenced by extension_registry.c
>>>               extension_registry.o:(upb_ExtensionRegistry_AddAllLinkedExtensions) in archive bazel-out/aarch64-opt-exec-ST-12dfad941fb6/bin/external/protobuf+/upb/mini_table/libmini_table.ald.lld: error: undefined symbol: __start_linkarr_upb_AllExts>>> referenced by extension_registry.c
>>>               extension_registry.o:(upb_ExtensionRegistry_AddAllLinkedExtensions) in archive bazel-out/aarch64-opt-exec-ST-12dfad941fb6/bin/external/protobuf+/upb/mini_table/libmini_table.a
>>> referenced by extension_registry.c
>>>               extension_registry.o:(upb_ExtensionRegistry_AddAllLinkedExtensions) in archive bazel-out/aarch64-opt-exec-ST-12dfad941fb6/bin/external/protobuf+/upb/mini_table/libmini_table.a
>>> the encapsulation symbol needs to be retained under --gc-sections properly; consider -z nostart-stop-gc (see https://lld.llvm.org/ELF/start-stop-gc)

And Bazel fails with:

ERROR: .../external/protobuf+/upb/reflection/BUILD:28:28 Compiling external/protobuf+/upb/reflection/stage1/google/protobuf/descriptor.upb_minitable.c [for tool] failed: (Exit 1): c++ failed: error executing CppLink command (from target @@protobuf+//upb_generator/minitable:protoc-gen-upb_minitable_stage0) 

We do use a hermetic CC toolchain based on Zig:

# C++ toolchain
bazel_dep(name = "hermetic_cc_toolchain", version = "4.0.1")

toolchains = use_extension("@hermetic_cc_toolchain//toolchain:ext.bzl", "toolchains")
use_repo(toolchains, "zig_sdk")

register_toolchains(
    # execution HOST platform
    "@zig_sdk//toolchain:linux_amd64_gnu.2.17",
    "@zig_sdk//toolchain:linux_arm64_gnu.2.17",

    # CentOS 7 compatible toolchains
    "@zig_sdk//libc_aware/toolchain:linux_amd64_gnu.2.17",
    "@zig_sdk//libc_aware/toolchain:linux_arm64_gnu.2.17",

    ...
)

Downgrading to 30.2 helps.