加-fPIC是必须的，因为动态库加载地址由运行时决定，非PIC代码含绝对地址无法安全重定位，会导致relocation错误或崩溃。
为什么加 -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 风格的创建/销毁/操作函数。
立即学习“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 或匿名命名空间隔离。
