前段时间例行升级我为游戏框架写的构建系统 cmake-toolset 时，又遇到了 protobuf 的一个新 ABI 兼容性问题。
这已经不是第一次被 protobuf 的 ABI 兼容性问题“教育”了。这篇把问题拆开讲清楚，并给出一套可落地的规避方案，供遇到类似问题的同学参考。
首先在链接阶段出现错误：
[build] test_pb.pb.obj : error LNK2001: 无法解析的外部符号 "class google::protobuf::internal::GlobalEmptyStringConstexpr const google::protobuf::internal::fixed_address_empty_string" (?fixed_address_empty_string@internal@protobuf@google@@3VGlobalEmptyStringConstexpr@123@B) [D:\workspace\git\github\atframework\cmake-toolset\test\build_jobs_dir\cmake-toolset-test.vcxproj]
[build] D:\workspace\git\github\atframework\cmake-toolset\test\build_jobs_dir\bin\Debug\cmake-toolset-test.exe : fatal error LNK1120: 1 个无法解析的外部命令 [D:\workspace\git\github\atframework\cmake-toolset\test\build_jobs_dir\cmake-toolset-test.vcxproj]
我也在 opentelemetry-cpp 社区提了一个同样现象的 issue（见 open-telemetry/opentelemetry-cpp#3799）。
为了说明问题，我们把“生成代码”和“protobuf 库本体”的相关片段并排看一下。
.pb.cc生成的 .pb.cc 里会出现类似这样的代码（把 std::string 的默认值初始化为一个固定地址的空串）：
inline constexpr EntityRef::Impl_::Impl_(
::_pbi::ConstantInitialized) noexcept
: id_keys_{},
description_keys_{},
schema_url_(
&::google::protobuf::internal::fixed_address_empty_string,
::_pbi::ConstantInitialized()),
type_(
&::google::protobuf::internal::fixed_address_empty_string,
::_pbi::ConstantInitialized()),
_cached_size_{0} {}
port.h / port.cc）protobuf 的 port.h 里有如下定义（简化摘录）：
class alignas(8) GlobalEmptyStringConstexpr {
public:
const std::string& get() const { return value_; }
// Nothing to init, or destroy.
std::string* Init() const { return nullptr; }
template <typename T = std::string, bool = (T(), true)>
static constexpr std::true_type HasConstexprDefaultConstructor(int) {
return {};
}
static constexpr std::false_type HasConstexprDefaultConstructor(char) {
return {};
}
private:
std::string value_;
};
using GlobalEmptyString = std::conditional_t<
GlobalEmptyStringConstexpr::HasConstexprDefaultConstructor(0),
const GlobalEmptyStringConstexpr, GlobalEmptyStringDynamicInit>;
PROTOBUF_EXPORT extern GlobalEmptyString fixed_address_empty_string;
对应的 port.cc 里会定义这个全局对象：
PROTOBUF_ATTRIBUTE_NO_DESTROY PROTOBUF_CONSTINIT
PROTOBUF_ATTRIBUTE_INIT_PRIORITY1 GlobalEmptyString
fixed_address_empty_string{};
查阅 C++ 文档（例如 https://en.cppreference.com/w/cpp/string/basic_string/basic_string.html）可以看到：std::string 的构造函数是在 C++20 之后才逐步具备 constexpr 能力。
这意味着：
GlobalEmptyStringConstexpr::HasConstexprDefaultConstructor(0) 可能成立，GlobalEmptyString 会走到 GlobalEmptyStringConstexpr 路径。GlobalEmptyString 会走到另一条类型分支。而如果你的工程里出现了“protobuf 库”和“.pb.cc”采用不同 C++ 标准编译，且跨越了 C++20 这条分界线，那么：
GlobalEmptyStringConstexpr 为前提；最终就会出现前面那种链接错误（LNK2001）。
一句话：不要让 “protobuf 库” 和 “生成的 .pb.cc” 在 C++20 前后混用。
最理想的做法当然是全工程统一 C++ 标准（例如都用 C++20），并用同一套工具链把 protobuf/abseil 也一起重编。
但现实里经常会遇到“依赖是预编译包”的情况，这时就需要在 CMake 层面尽量推断 protobuf 的“实际编译标准”，并把 .pb.cc 的编译标准对齐到不会产生 ABI 差异的范围。
如果 protobuf 是通过 CMake package 导入的，导出的目标里一般会带 INTERFACE_COMPILE_FEATURES，例如：
set_target_properties(protobuf::libprotobuf PROPERTIES
INTERFACE_COMPILE_FEATURES "cxx_std_17"
INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
INTERFACE_LINK_LIBRARIES "\$<LINK_ONLY:ZLIB::ZLIB>;absl::absl_check;absl::absl_log;absl::algorithm;absl::base;absl::bind_front;absl::bits;absl::btree;absl::cleanup;absl::cord;absl::core_headers;absl::debugging;absl::die_if_null;absl::dynamic_annotations;absl::flags;absl::flat_hash_map;absl::flat_hash_set;absl::function_ref;absl::hash;absl::if_constexpr;absl::layout;absl::log_initialize;absl::log_globals;absl::log_severity;absl::memory;absl::node_hash_map;absl::node_hash_set;absl::optional;absl::random_distributions;absl::random_random;absl::span;absl::status;absl::statusor;absl::strings;absl::synchronization;absl::time;absl::type_traits;absl::utility;absl::variant;\$<LINK_ONLY:utf8_range::utf8_validity>"
)
我们可以读取 INTERFACE_COMPILE_FEATURES，尝试获得 cxx_std_NN 并用于约束生成的 proto targets。
我在 cmake-toolset 里原本就有一个 “patch protobuf 生成代码 target” 的接口（主要用来屏蔽 protobuf 生成代码触发的严格告警）。这次我把它扩展为：如果能推断出 protobuf 的 C++ 标准，就显式把生成的 .pb.cc target 对齐过去。
function(project_build_tools_patch_protobuf_targets)
# 如果之前找到了 cxx_std_NN 的 INTERFACE_COMPILE_FEATURES, 就把 ATFRAMEWORK_CMAKE_TOOLSET_THIRD_PARTY_PROTOBUF_CXX_STANDARD 设置成这个标准数字部分
if(ATFRAMEWORK_CMAKE_TOOLSET_THIRD_PARTY_PROTOBUF_CXX_STANDARD)
foreach(PROTO_TARGET ${ARGN})
set_target_properties(${PROTO_TARGET} PROPERTIES CXX_STANDARD
${ATFRAMEWORK_CMAKE_TOOLSET_THIRD_PARTY_PROTOBUF_CXX_STANDARD})
endforeach()
if(MSVC)
set(__additional_cxx_standard "/std:c++${ATFRAMEWORK_CMAKE_TOOLSET_THIRD_PARTY_PROTOBUF_CXX_STANDARD}")
else()
set(__additional_cxx_standard "-std=c++${ATFRAMEWORK_CMAKE_TOOLSET_THIRD_PARTY_PROTOBUF_CXX_STANDARD}")
endif()
endif()
foreach(PROTO_TARGET ${ARGN})
set(PROTO_TARGET_OPTIONS_CHANGED FALSE)
get_target_property(PROTO_TARGET_OPTIONS ${PROTO_TARGET} COMPILE_OPTIONS)
if(PROTO_TARGET_OPTIONS)
set(__need_cxx_standard TRUE)
if(NOT ATFRAMEWORK_CMAKE_TOOLSET_THIRD_PARTY_PROTOBUF_CXX_STANDARD
OR PROTO_TARGET_OPTIONS MATCHES
"(/std:|-std=)(c|gnu)\\+\\+${ATFRAMEWORK_CMAKE_TOOLSET_THIRD_PARTY_PROTOBUF_CXX_STANDARD}")
set(__need_cxx_standard FALSE)
else()
if(MSVC)
string(REGEX REPLACE "/std:c\\+\\+[0-9a-zA-Z_]+" "" PROTO_TARGET_OPTIONS "${PROTO_TARGET_OPTIONS}")
endif()
string(REGEX REPLACE "-std=(c|gnu)\\+\\+[0-9a-zA-Z_]+" "" PROTO_TARGET_OPTIONS "${PROTO_TARGET_OPTIONS}")
set(__need_cxx_standard TRUE)
endif()
# 我们原来有一些根据编译环境生产的Patch编译选项，放在 PROJECT_BUILD_TOOLS_PATCH_PROTOBUF_SOURCES_OPTIONS ，这里是做融合
foreach(TEST_OPTION ${PROJECT_BUILD_TOOLS_PATCH_PROTOBUF_SOURCES_OPTIONS})
if(NOT "${TEST_OPTION}" IN_LIST PROTO_TARGET_OPTIONS)
list(APPEND PROTO_TARGET_OPTIONS "${TEST_OPTION}")
set(PROTO_TARGET_OPTIONS_CHANGED TRUE)
endif()
endforeach()
if(__need_cxx_standard)
list(APPEND PROTO_TARGET_OPTIONS "${__additional_cxx_standard}")
set(PROTO_TARGET_OPTIONS_CHANGED TRUE)
endif()
else()
set(PROTO_TARGET_OPTIONS ${PROJECT_BUILD_TOOLS_PATCH_PROTOBUF_SOURCES_OPTIONS})
if(__additional_cxx_standard)
list(APPEND PROTO_TARGET_OPTIONS "${__additional_cxx_standard}")
endif()
set(PROTO_TARGET_OPTIONS_CHANGED TRUE)
endif()
if(PROTO_TARGET_OPTIONS_CHANGED)
set_target_properties(${PROTO_TARGET} PROPERTIES COMPILE_OPTIONS "${PROTO_TARGET_OPTIONS}")
endif()
endforeach()
endfunction()
不过把这个策略落下去之后，又遇到了两个“二次踩坑”。这俩坑的共同点是：仅凭 cxx_std_NN 并不足以推断“实际在用的编译标准/ABI约束”。
cxx_std_NN 可能不准确上游工程实际使用了 C++17：
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\include\string_view(12): warning STL4038: The contents of <string_view> are available only with C++17 or later. [D:\a\opentelemetry-cpp\opentelemetry-cpp\build\opentelemetry_proto.vcxproj]
(compiling source file '../../../../generated/third_party/opentelemetry-proto/opentelemetry/proto/common/v1/common.pb.cc')
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\include\vector(29,1):
see declaration of 'std'
D:\a\opentelemetry-cpp\opentelemetry-cpp\tools\vcpkg\installed\x64-windows\include\absl\strings\string_view.h(53,26): error C2061: syntax error: identifier 'string_view' [D:\a\opentelemetry-cpp\opentelemetry-cpp\build\opentelemetry_proto.vcxproj]
(compiling source file '../../../../generated/third_party/opentelemetry-proto/opentelemetry/proto/common/v1/common.pb.cc')
但 protobuf 导出的 package 却声称自己是 cxx_std_14 （某些老一些的版本）：
get_target_property(protobuf_lib_compile_features protobuf::libprotobuf INTERFACE_COMPILE_FEATURES)
if(protobuf_lib_compile_features MATCHES "(^|\\s)cxx_std_([0-9]+)(|$\\s)")
message(
STATUS
"protobuf::libprotobuf detected compile features cxx_std_${CMAKE_MATCH_2}."
)
endif()
输出是 -- protobuf::libprotobuf detected compile features cxx_std_14.。
所以这里的处理思路是：不要完全依赖 cxx_std_NN，而是把 C++20 作为 ABI 分界线。
如果你的工程整体用的是 C++20（或更高），而导入的 protobuf “看起来”低于 C++20，那么就需要避免让 .pb.cc 跨过 C++20；反过来也同理。
if(DEFINED CMAKE_CXX_STANDARD AND protobuf_lib_compile_features MATCHES
"(^|\\s)cxx_std_([0-9]+)(|$\\s)")
# Whether the protobuf library using C++20 or higher may have different
# ABI. We need to make sure our proto targets are using the same C++
# standard.
if(${CMAKE_MATCH_2} LESS 20 AND CMAKE_CXX_STANDARD GREATER_EQUAL 20)
# Some versions of protobuf will set cxx_std_14, but actually require
# c++17
set(protobuf_lib_compile_features_cxx_std 17)
elseif(${CMAKE_MATCH_2} GREATER_EQUAL 20 AND CMAKE_CXX_STANDARD LESS 20)
set(protobuf_lib_compile_features_cxx_std ${CMAKE_MATCH_2})
endif()
message(
STATUS
"protobuf::libprotobuf detected compile features cxx_std_${CMAKE_MATCH_2}."
)
endif()
在 Linux + GCC 上，如果你把 .pb.cc 强行降到 C++17，可能会遇到如下编译错误：
[ 2%] Building CXX object CMakeFiles/opentelemetry_proto.dir/generated/third_party/opentelemetry-proto/opentelemetry/proto/resource/v1/resource.pb.cc.o
In file included from /usr/local/include/absl/numeric/int128.h:41,
from /usr/local/include/absl/strings/internal/str_format/arg.h:35,
from /usr/local/include/absl/strings/str_format.h:83,
from /usr/local/include/absl/crc/crc32c.h:32,
from /usr/local/include/absl/crc/internal/crc_cord_state.h:23,
from /usr/local/include/absl/strings/cord.h:80,
from /usr/local/include/google/protobuf/io/coded_stream.h:111,
from /home/runner/build/generated/third_party/opentelemetry-proto/opentelemetry/proto/resource/v1/resource.pb.h:20,
from /home/runner/build/generated/third_party/opentelemetry-proto/opentelemetry/proto/resource/v1/resource.pb.cc:6:
/usr/local/include/absl/types/compare.h:60:12: error: ‘partial_ordering’ has not been declared in ‘std’
60 | using std::partial_ordering;
| ^~~~~~~~~~~~~~~~
/usr/local/include/absl/types/compare.h:61:12: error: ‘strong_ordering’ has not been declared in ‘std’
61 | using std::strong_ordering;
| ^~~~~~~~~~~~~~~
/usr/local/include/absl/types/compare.h:62:12: error: ‘weak_ordering’ has not been declared in ‘std’
62 | using std::weak_ordering;
| ^~~~~~~~~~~~~
/usr/local/include/absl/types/compare.h:455:56: error: ‘weak_ordering’ in namespace ‘absl’ does not name a type
455 | constexpr bool compare_result_as_less_than(const absl::weak_ordering r) {
| ^~~~~~~~~~~~~
/usr/local/include/absl/types/compare.h:470:17: error: ‘weak_ordering’ in namespace ‘absl’ does not name a type
470 | constexpr absl::weak_ordering compare_result_as_ordering(const Int c) {
这里涉及 Three-way comparison（C++20 引入的 <compare> 与 std::weak_ordering 等类型）。当 abseil 在安装/打包阶段被“按 C++20 可用”来配置过，而你的 .pb.cc 又用 C++17 编译时，就会出现这种 “头文件里 using std::weak_ordering; 但标准库并未提供” 的报错。
这也说明了：即便你只想“把 .pb.cc 降回 C++17 来贴合 protobuf 的 ABI”，也必须确保 abseil 的配置/编译假设不会被打破。
此外还有一个容易误判的点：一些 protobuf 版本会写 target_compile_features("${target}" PUBLIC cxx_std_17)，但如果你在构建 protobuf 时设置了 -DCMAKE_CXX_STANDARD=20，那么它实际可能会用 C++20 编译，可导出的 package 信息仍然停留在 cxx_std_17。这会让“靠 package 元信息推断 ABI”变得更不可靠。
因此，更稳妥（但成本更高）的思路是：在工具链层面做一个小探针，分别用 -std=c++17 和 -std=c++20（或 MSVC 对应的 /std:c++XX）尝试编译/链接一个最小样例，判断当前安装的 protobuf/abseil 组合到底要求哪个标准。
#include <iostream>
#include <google/protobuf/message.h>
int main () {
std::cout<< ::google::protobuf::internal::fixed_address_empty_string.get()<< std::endl;
return 0;
}
当然实际情况还和 protobuf/abseil 具体版本、打包方式、编译器/标准库实现有关，落地时要保留余地。
不过实际上，在Linux+GCC 13里，protobuf用C++17，而 .pb.cc 使用C++20是没问题的。因为这样虽然符号表里有非 constexpr 的分支，但是编译 .pb.cc 的时候，整个 fixed_address_empty_string 走编译期计算了。
因为 constexpr 并不是强制性的编译期评估（ consteval 才是 ）,所以如果依赖这个行为的话会和编译环境、编译器版本相关。而恰好MSVC没有全部走编译期计算，所以触发了这个问题。
截至写作时间，最新 protobuf 主干分支已经把相关逻辑改成了下面这样：在 MSVC 下强制禁用 constexpr std::string 的那条优化路径，从而规避跨标准导致的符号不一致问题。
这类改动在发布版落地之前，可以视作一个“临时止血方案”（前提是你能升级到包含该修复的版本/提交，或在自维护分支里 backport）。
// Take advantage of C++20 constexpr support in std::string.
class alignas(8) GlobalEmptyStringConstexpr {
public:
const std::string& get() const { return value_; }
// Nothing to init, or destroy.
std::string* Init() const { return nullptr; }
// Disable the optimization for MSVC and Xtensa.
// There are some builds where the default constructed string can't be used as
// `constinit` even though the constructor is `constexpr` and can be used
// during constant evaluation.
#if !defined(_MSC_VER) && !defined(__XTENSA__)
// Compilation fails on Xtensa: b/467129751
template <typename T = std::string, bool = (T(), true)>
static constexpr std::true_type HasConstexprDefaultConstructor(int) {
return {};
}
#endif
static constexpr std::false_type HasConstexprDefaultConstructor(char) {
return {};
}
private:
std::string value_;
};
Google 生态下 protobuf 的坑确实不少。如果你对我之前踩过的其他 protobuf 相关坑感兴趣，可以直接在 Blog 里搜关键词 protobuf。
欢迎小伙伴们交流拍砖。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。