重定义C++共享库公有类方法是否具备跨编译器跨系统兼容性？

你在Linux GCC环境下观察到的效果，完全依赖于ELF格式动态链接器的默认符号介入规则，不属于C++标准保证的行为，换其他环境大概率无法复现。

生效的核心原因 #

Linux下ELF格式的动态链接器默认启用全局符号覆盖机制：加载符号时会优先使用最先加载的二进制目标中的同名符号。你的主程序编译时已经包含了Myclass::set_myval的定义，加载顺序早于动态库，所以不管是主程序还是动态库内部对该方法的调用，都会被重定向到你重写的版本。

会失效的常见场景 #

• Windows系统：PE格式的动态链接完全没有默认符号介入逻辑，动态库内部的函数调用默认直接绑定到库内部的实现，你在主程序重定义该方法要么直接报符号重复定义的编译错误，要么动态库内部仍然调用自己的原始实现，完全达不到预期效果。
• Linux下修改编译链接参数：就算是同环境，只要参数调整就会失效：
  • 编译动态库时加了-fvisibility=hidden，会把类方法的符号设为隐藏，动态库内部调用直接绑定到本地实现，主程序无法覆盖
  • 链接动态库时加了-Bsymbolic/-Bsymbolic-functions参数，会强制动态库优先绑定内部符号，忽略主程序的重定义
  • 编译动态库时开了高优化等级，编译器可能直接把set_myval的逻辑内联到set_myval_v2里，连符号调用都不存在，根本没有覆盖的可能
• 标准层面风险：该操作本身违反C++的单一定义规则（ODR），同一个非内联非虚的类方法在整个程序中出现两个定义，本身就是未定义行为，当前的效果只是Linux动态链接器的特定实现刚好符合你的预期，没有任何标准保证不同平台/编译器会有相同的处理逻辑。

内容的提问来源于stack exchange，提问作者anymous.asker