为什么加 -fPIC 是必须的

Linux 下动态库（.so）被加载时，地址由动态链接器在运行时决定，不是编译时固定的。如果目标文件没用 -fPIC 编译，生成的机器码里会含绝对地址跳转或数据引用，无法安全重定位到任意内存位置——加载直接失败或运行时崩溃。

常见错误现象：relocation R_X86_64_32 against `.rodata' can not be used when making a shared object，就是没加 -fPIC 的典型报错。

• -fPIC 生成位置无关代码，所有跳转和数据访问都通过 GOT/PLT 间接完成
• -fPIE 是给可执行文件用的，别和 -fPIC 混用在库上
• 即使只有一行 int x = 42;，只要它被导出或被导出函数引用，就可能触发重定位错误

如何正确导出 C++ 函数和类（避免符号名扭曲）

C++ 默认启用名称修饰（name mangling），同一个函数在符号表里是类似 _Z9addIntsii 这样的乱码。其他语言（如 Python/C）或 C 接口根本没法调用。导出接口必须显式控制符号可见性或用 extern "C" 封装。

推荐做法：只对真正需要被外部调用的函数加 extern "C"，类不建议直接导出（虚表、ABI 兼容性太脆弱）；如需封装类，提供 C 风格的创建/销毁/操作函数。

• 头文件中声明导出函数时，用 #ifdef __cplusplus 包裹 extern "C"
• 全局变量不能用 extern "C" 导出，只能通过函数返回指针
• 使用 __attribute__((visibility("default"))) 可以精细控制单个符号，但需配合编译选项 -fvisibility=hidden 才有效

// math_api.h
#ifdef __cplusplus
extern "C" {
#endif

int add_ints(int a, int b);
int multiply_ints(int a, int b);

#ifdef __cplusplus
}
#endif

编译与链接命令要分开写，别一步到位

新手常把源码直接丢进 g++ -shared -o libmath.so *.cpp，看似省事，实则埋雷：没加 -fPIC、没设 visibility、没指定标准库链接方式，导致库在不同环境加载失败。

正确流程是「先编译成 PIC 对象，再链接成 so」，中间可插检查步骤。

• 编译阶段必须加 -fPIC，且建议加上 -std=c++17 和 -fvisibility=hidden
• 链接阶段用 -shared，并加 -Wl,-soname,libmath.so.1 设定 soname
• 不要用 -static-libstdc++，否则会把 libstdc++ 打包进去，引发 ABI 冲突

g++ -fPIC -fvisibility=hidden -std=c++17 -c math_impl.cpp -o math_impl.o
g++ -shared -Wl,-soname,libmath.so.1 -o libmath.so.1.0.0 math_impl.o
ln -sf libmath.so.1.0.0 libmath.so.1
ln -sf libmath.so.1 libmath.so

怎么验证导出符号是否干净可用

编译完别急着用，先用工具确认实际导出的符号是不是你想要的，有没有意外暴露的 C++ 符号或 STL 内部符号。

• 用 nm -D libmath.so 查看动态符号表，只应看到你用 extern "C" 声明的函数名（如 add_ints），而不是 _Z9addIntsii
• 用 objdump -T libmath.so 看符号类型和绑定，确保是 FUNC GLOBAL DEFAULT
• 用 readelf -d libmath.so | grep NEEDED 检查依赖，不应出现 libstdc++.so.6 以外的非常规依赖（比如本地路径的库）

如果 nm -D 输出里混着大量 __cxx11 或 std:: 开头的符号，说明有类成员函数或模板实例被意外导出，得回代码里加 static 或匿名命名空间隔离。