clang/gcc动态库默认导出所有非static全局符号，易致符号冲突；应启用-fvisibility=hidden并显式标记导出接口，extern "c"函数须加唯一前缀，静态库需源头控制符号可见性，上线前必用nm/readelf验证导出表。
Clang编译的动态库导出太多符号，导致运行时覆盖
Clang（和GCC）默认会把所有非 static 的全局函数/变量都导出到动态库符号表里，哪怕它们只是内部工具函数。两个库都定义了 helper_parse()，dlopen 加载后，后加载的那个可能被前一个“遮住”，或者触发弱符号覆盖逻辑，行为不可控。
必须在编译阶段就切断默认导出链：
- 统一加编译选项
-fvisibility=hidden，让所有符号默认不导出 - 只对真正需要暴露的接口，用
__attribute__((visibility("default")))显式标记 - 头文件中定义导出宏，比如
#define MYLIB_API __attribute__((visibility("default")))，避免手写重复 - 检查 C++ 类成员函数：它们默认不导出，但若类声明加了
MYLIB_API，整个类的虚表、构造函数等也会导出——要小心
extern "C" 函数名没加前缀，一加载就撞车
一旦用了 extern "C"，C++ 的 name mangling 就失效，namespace MyLib { void init(); } 在符号表里还是变成裸名 init。如果另一个库也导出 init，Linux 动态链接器直接选一个（通常是先加载的），你根本控制不了。
解决办法不是套 namespace，而是改名：
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
- 所有
extern "C"导出函数必须带唯一前缀，例如mylib_init()、mylib_v2_process() - 前缀要能体现库名+主版本号，避免未来升级再冲突
- 函数体内再调用真正的命名空间实现：
return MyLib::Core::process(); - 别信“我只用一次，不会撞”——第三方 SDK、系统库、甚至 glibc 里都有大量同名 C 接口（如
log、init、config）
用 nm -D 和 readelf -Ws 看清实际导出了什么
别等程序跑飞了才查。上线前必须人工确认动态库导出表是否干净：
-
nm -D libmylib.so | grep ' T '列出所有导出的函数（T 表示文本段） -
readelf -Ws libmylib.so | grep 'FUNC.*GLOBAL'更准确，过滤掉局部符号 - 重点扫一眼有没有漏网之鱼：没加
visibility("hidden")的辅助函数、调试用的dump_state()、日志里的log_debug() - 如果看到大量未加前缀的裸名（尤其是短名字），立刻回退编译选项或补宏
多个动态库都依赖同一个静态库，引发间接符号污染
比如 libA.so 和 libB.so 都静态链接了 common_utils.a，而这个静态库里的 str_to_int() 没加 static 或匿名命名空间——结果两个动态库都导出了同名符号，加载顺序决定谁胜出。
这种问题藏得深，必须从静态库源头处理：
- 静态库源码中，所有非对外接口一律加
static，或包进namespace { ... } - 编译静态库时也加
-fvisibility=hidden（虽然对 .a 文件本身无影响，但能约束后续动态库引用它的行为） - 如果无法修改静态库源码，就在构建动态库时用链接器脚本（version script）或
--exclude-libs把它里面的符号彻底剥离 - Clang 不支持
--exclude-libs，得换用ld.lld并配 version script
最常被忽略的一点：符号冲突往往不报错，只在特定加载顺序、特定调用路径下静默出错。别依赖“现在能跑通”，一定要用 nm 和 readelf 主动翻导出表——眼睛看得到的，才是可控的。
