静态库.a是.o目标文件的归档，不可还原源码；其.o默认非PIC，不能直接用于构建.so，须用-fPIC重新编译源码生成PIC目标文件后，再-shared链接成动态库。
静态库 .a 不能“解包成源码”，但可以提取出 .o 文件
你没法从 libxxx.a 里还原出原始的 .c 或 .cpp 文件——.a 是多个 .o 目标文件的归档，不带调试信息或源码映射时，就只剩机器指令和符号表。但只要你没 strip 过，且这些 .o 是用默认方式（非 -fPIC）编译的，那它们本身**不能直接用于生成动态库**。
关键点在于：.so 要求所有目标文件必须是位置无关代码（PIC），而普通 gcc -c xxx.c 生成的 .o 默认不是 PIC。强行用非 PIC 的 .o 打 .so 会报错：
relocation R_X86_64_32 against `.rodata' can not be used when making a shared object
所以“解包→重打包”不是复制粘贴操作，而是：提取 → 检查 → 重新编译为 PIC → 再链接。
用 ar 和 objdump 确认 .o 是否支持 PIC
先解包 libxxx.a：
ar -x libxxx.a
你会得到一堆 xxx.o。接着检查其中任意一个是否含 R_X86_64_RELATIVE 类重定位（PIC 标志）：
-
objdump -d xxx.o | grep "R_X86_64_RELATIVE"—— 有输出说明已含 PIC 重定位（极少见） -
readelf -d xxx.o | grep TEXTREL—— 若输出为空，才可能安全用于.so；若出现TEXTREL条目，说明它依赖绝对地址，绝对不能用于动态库
99% 的常规静态库 .a 都不含 PIC，所以下一步不是“打包”，而是“重编译”。
必须用 -fPIC 重新编译源码，不能跳过这步
如果你还保留着原始源码（比如 add.cpp, calc.cpp），这才是正确路径：
- 用
g++ -fPIC -c add.cpp -o add.o逐个生成 PIC 目标文件 - 确认没有警告或错误，尤其注意模板、内联函数、全局变量初始化等可能隐式依赖绝对地址的地方
- 再用
g++ -shared -o libxxx.so add.o calc.o打包
如果你**没有源码**，只有 .a，那基本无解：非 PIC 的 .o 无法在不修改二进制的前提下转成 PIC。有人尝试用 objcopy --redefine-sym 或 patch 重定位表，但成功率低、不可靠、且违反 ABI 约束，不建议生产环境使用。
链接时 -lxxx 找不到新生成的 .so？检查 soname 和 RPATH
即使你成功生成了 libxxx.so，用 g++ main.cpp -L. -lxxx 编译后，运行仍可能报 libxxx.so: cannot open shared object file。原因常有两个：
-
libxxx.so的soname不是libxxx.so：用readelf -d libxxx.so | grep SONAME查看，若显示libxxx.so.1，就得确保运行时能搜到那个名字（软链接或改名） - 可执行文件没嵌入搜索路径：加
-Wl,-rpath,'$ORIGIN'让它运行时从自身目录找.so，否则只查/lib、/usr/lib和LD_LIBRARY_PATH
真正容易被忽略的是：.a 到 .so 不是格式转换，而是构建策略变更。你得接受——没有源码，这条路走不通；有源码，就别碰 .a，直接走 -fPIC + -shared 流程。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
