必须加-fPIC和-shared：-fPIC生成位置无关代码以支持动态加载时任意内存地址定位，-shared使链接器生成动态段、导出符号表并允许运行时解析；缺一不可，否则导致undefined symbol或cannot make .dynamic错误。
直接上手做，gcc -shared -fPIC 是唯一必须的组合，漏掉任一参数都会导致运行时报 undefined symbol 或 cannot make .dynamic for shared object 错误。
为什么必须加 -fPIC 和 -shared
动态库不是把代码“塞进”可执行文件里，而是让运行时加载器（ld.so）在内存中任意位置加载并解析符号。没 -fPIC 的目标文件含绝对地址，加载到非预期地址就会跳错；没 -shared，GCC 默认按可执行格式生成，缺少动态段（.dynamic），ldconfig 甚至无法识别它为合法动态库。
-
-fPIC生成 GOT/PLT 表，所有数据访问和函数调用都走间接寻址 -
-shared触发链接器生成动态段、导出符号表，并禁用未定义符号报错（允许运行时解析） - 二者缺一不可——
gcc -c -fPIC hello.c只是中间步骤，最终必须gcc -shared -fPIC -o libhello.so hello.o
gcc -shared 的常见错误命令和修复
新手常写错这三类命令，结果编译通过但运行失败：
- 错：
gcc -o libhello.so hello.o→ 生成的是普通可执行文件，不是动态库 - 错：
gcc -shared -o libhello.so hello.o→ 缺-fPIC，x86_64 下直接报错：relocation R_X86_64_32 against `.rodata' can not be used when making a shared object - 错：
gcc -shared -fPIC -o libhello.so main.c→ 把主程序源码直接编进去，导致库含main符号，被其他程序链接时冲突 - 正： 先
gcc -c -fPIC hello.c -o hello.o，再gcc -shared -fPIC -o libhello.so hello.o
运行时报 libhello.so: cannot open shared object file 怎么办
这不是编译问题，是运行时路径没配对。Linux 不会自动查当前目录，只认 /lib64、/usr/lib64 和 LD_LIBRARY_PATH 中的路径。
- 临时解决：
LD_LIBRARY_PATH=. ./main（注意.在等号后不能有空格） - 永久生效（仅开发机）：
sudo cp libhello.so /usr/lib64/ && sudo ldconfig - 更安全的做法：用
patchelf修改可执行文件的RPATH，例如patchelf --set-rpath '$ORIGIN' ./main，这样运行时就在可执行文件同目录找.so - 验证是否生效：
ldd ./main | grep hello应显示libhello.so => ./libhello.so (0x...)
如何避免符号污染和 ABI 不兼容
默认情况下，.so 会导出所有全局符号（包括内部辅助函数），容易引发命名冲突或意外调用。
- 加
-fvisibility=hidden编译.o，再用__attribute__((visibility("default")))显式标记要导出的函数 - 用
objdump -T libhello.so检查实际导出符号，确认只有hello等必要函数 - 升级库时若修改函数签名（如
void hello(int)→void hello(const char*)），必须改库名（如libhello.so.2）并更新SONAME，否则旧程序加载新库会崩溃
最易被忽略的一点：即使你只改了 .c 文件里的一个字符，也必须重新 gcc -c -fPIC 再 gcc -shared —— 直接复用旧 .o 文件可能因编译器版本或优化选项差异，导致 GOT 偏移错位，运行时随机崩溃。
