Clang/GCC默认导出所有非static全局符号，是多模块符号冲突的根源；必须启用-fvisibility=hidden并显式标记__attribute__((visibility("default")))才能精准导出所需接口。
Clang编译时默认导出所有非static符号，这是冲突根源
Clang（和GCC）在生成动态库时，默认把所有非static的全局符号都导出，哪怕你写了namespace MyLib { void helper(); }，只要没显式隐藏，helper就会出现在libmylib.so的导出表里。运行时若另一个库也导出了同名helper，dlopen后就可能被覆盖或引发ABI不兼容崩溃。
这不是“命名空间没写对”的问题，而是链接器看到两个同名裸符号（尤其是extern "C"函数）或相同mangled名时的自然行为。
-
-fvisibility=hidden必须加在编译命令里，不是可选优化项 - 只靠
namespace完全不能阻止符号导出——它只影响name mangling，不影响链接器可见性 - 即使类成员函数没加
__attribute__((visibility("default")))，只要类本身被标记为default，其非静态成员也会自动导出
怎么只导出真正需要的接口
启用-fvisibility=hidden后，所有符号默认不可见；你要做的，是**主动、显式**地标记那些必须对外暴露的符号。
推荐方式：用extern "C"封装一层带前缀的C风格函数，再内部调用真正的C++实现：
// mylib_api.h
#ifdef __cplusplus
extern "C" {
#endif
<p><strong>attribute</strong>((visibility("default"))) void mylib_init();
<strong>attribute</strong>((visibility("default"))) int mylib_process_data(const char* input);</p><h1>ifdef __cplusplus</h1><p>}</p><h1>endif</h1><p>对应实现里不暴露任何C++细节：
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
// mylib_api.cpp
#include "mylib_api.h"
#include "core_impl.hpp" // 实际逻辑在命名空间内，且不导出
<p>void mylib_init() {
MyLib::Core::initialize();
}</p><p>int mylib_process_data(const char* input) {
return MyLib::Core::process(input);
}
- 头文件中所有
extern "C"函数都加__attribute__((visibility("default"))) -
core_impl.hpp里的函数全部用static、匿名命名空间，或确保不被任何visibility("default")符号间接引用 - 避免在头文件里定义inline函数，除非加
static或inline+__attribute__((visibility("hidden")))
检查是否真没导出多余符号
别等上线才发现冲突。每次生成so后，立刻用readelf -Ws libmylib.so | grep GLOBAL | grep FUNC看导出函数列表。正常情况应该只有几个带前缀的函数，比如mylib_init、mylib_process_data。
如果看到_ZN6MyLib5helperEv这类mangled名，说明有C++符号意外导出：
- 确认所有.cpp文件都加了
-fvisibility=hidden（不是只在主构建脚本里加，每个编译单元都要） - 检查是否漏掉了某个
class或function没加__attribute__((visibility("default")))，却通过头文件被外部间接引用 - 用
nm -D libmylib.so | c++filt辅助识别mangled名对应的原始符号
多个动态库共存时仍冲突？重点查加载顺序和符号绑定类型
即使每个库都做了正确导出控制，运行时仍可能因dlopen(RTLD_GLOBAL)把符号注入全局符号表，导致后加载的库覆盖先加载的同名符号。
这时要放弃“名字唯一”幻想，转而控制加载行为：
- 优先用
RTLD_LOCAL加载，避免符号泄漏到全局命名空间 - 如果必须用
RTLD_GLOBAL，确保所有库的导出函数名前缀绝对不重叠（比如libfoo用foo_，libbar用bar_） - 用
readelf -d libmylib.so | grep NEEDED检查依赖链，确认没有隐式依赖另一个可能导出冲突符号的库
最隐蔽的坑是：你以为自己没导出helper，但它被某个模板实例化或内联函数意外拖进了导出表——所以readelf检查不能跳过。
