动态库导出符号重名时，g++在链接阶段报multiple definition错误，根本原因是C++默认导出所有非静态全局符号，多个动态库或主程序定义同名强符号（如init_config）时，链接器ld拒绝合并；必须用-fvisibility=hidden显式控制可见性，默认隐藏、白名单导出。
动态库导出符号重名时，g++ 为什么报 multiple definition？
不是链接时才报错，而是编译期就可能触发 —— 当多个动态库（或主程序）都定义了同名的全局函数/变量（比如都叫 init_config），且未隐藏符号，ld 在链接阶段会拒绝合并重复的强符号。根本原因在于：C++ 默认导出所有非静态全局符号，extern "C" 块里更危险，连 C++ name mangling 都绕过了。
关键点：namespace 本身不阻止符号导出，它只影响编译期名字修饰；真正起作用的是符号可见性控制。
- 必须显式关闭默认导出（加
-fvisibility=hidden编译选项） -
namespace要配合__attribute__((visibility("default")))才能安全导出指定符号 - 头文件中避免用
using namespace xxx，否则可能意外拉入冲突符号
用 __attribute__((visibility)) 控制导出范围
这是最直接、跨平台兼容性较好的方式（GCC/Clang 支持，MSVC 用 __declspec(dllexport)）。核心原则：默认隐藏，仅对明确需要导出的符号开白名单。
示例：
立即学习“C++免费学习笔记（深入）”；
// mylib.h
#pragma once
#ifdef BUILD_MYLIB
# define MYLIB_API __attribute__((visibility("default")))
#else
# define MYLIB_API __attribute__((visibility("hidden")))
#endif
<p>namespace mylib {
MYLIB_API void init(); // ✅ 导出
void helper(); // ❌ 不导出（默认 hidden）
}</p><p>// mylib.cpp</p><h1>include "mylib.h"</h1><p>void mylib::init() { /<em> ... </em>/ }
void mylib::helper() { /<em> ... </em>/ } // 即使在 .cpp 里定义，也不导出
- 务必在编译动态库时加
-fvisibility=hidden，否则visibility("hidden")无效 - 不要给整个
namespace加 visibility 属性 —— C++ 标准不支持，GCC 会忽略 - 如果导出 C 接口，
extern "C"块内每个函数仍需单独标注MYLIB_API
为什么只靠 namespace 无法解决重名？
namespace 只改变编译器生成的 mangled 名（如 _ZN6mylib4initEv），但动态链接器（ld-linux.so）运行时看的是未修饰的符号名（init）—— 如果你用了 extern "C" 或导出了非成员函数，mangling 就失效了。
- 类成员函数天然带命名空间前缀，冲突概率低；但静态成员函数、自由函数、全局变量仍可能重名
- 两个库都导出
void log(const char*)，即使分别在ns_a::log和ns_b::log中定义，链接时看到的都是log符号 -
nm -D liba.so | grep log能直接验证实际导出的符号名，别依赖头文件结构做判断
加载时符号冲突：dlopen 后调用错了函数怎么办？
当两个动态库都导出同名符号（如 process_data），且都被 dlopen(RTLD_GLOBAL) 加载，后加载的库会覆盖前者的符号 —— 这是 ELF 的默认行为，不是 bug。
- 解决方案一：始终用
RTLD_LOCAL（推荐），然后通过dlsym显式获取函数指针，避免全局符号污染 - 解决方案二：用
objcopy --localize-symbol=xxx在构建后处理，把冲突符号转为 local - 绝对不要依赖“先加载哪个库就用哪个”，这在不同系统、不同
glibc版本下行为不一致
真正容易被忽略的是：符号可见性设置必须贯穿整个构建链 —— 从编译 .o、到打包 .so、再到最终链接可执行文件，漏掉任意一环（比如忘记给主程序加 -fvisibility=hidden），都可能导致本该隐藏的符号意外泄露。
