共享库原理与创建：共享库与位置无关代码(PIC)
说实话，共享库这个概念，我当年刚入行时也绕了不少弯路。那时候我总觉得，不就是把代码打个包嘛，跟静态库能有多大区别？直到有一次，我负责的一个大型项目在部署时出了大问题——同样的.so文件，在这台机器上跑得好好的，换一台就崩了。排查了整整两天，最后发现是编译时忘了加-fPIC。嗯，从那以后，我再也不敢小看这个选项了。
什么是共享库？
共享库，说白了就是一份可以被多个程序同时使用的代码仓库。你想想看，如果每个程序都把printf、malloc这些函数自己复制一份，那磁盘和内存得多浪费？共享库就是为了解决这个问题而生的。
在Linux上，它叫.so（Shared Object）；在Windows上，它叫.dll（Dynamic Link Library）；在macOS上，它叫.dylib（Dynamic Library）。名字不同，但核心思想是一样的——代码只存一份，运行时大家共享。
核心区别：静态库在编译时就把代码复制进可执行文件了，而共享库是在程序启动后（甚至运行时）才加载进来的。这意味着共享库可以独立更新，不用重新编译整个程序。
位置无关代码（PIC）
好，现在问题来了。共享库的代码，加载到内存的哪个地址？
静态库的代码在编译时就确定了地址，因为它是跟主程序一起链接的。但共享库不一样——它可能被多个程序同时使用，每个程序给它的地址空间都不一样。如果代码里写死了地址，那换个地方加载就完蛋了。
这就是PIC（Position Independent Code）要解决的问题。PIC代码里不包含绝对地址，所有地址引用都是相对的。加载器把库放到哪个地址，代码就能在哪个地址运行。
我个人的习惯是：只要编译共享库，一律加-fPIC。别问为什么，问就是吃过亏。
-fPIC 编译选项
-fPIC是GCC的一个编译选项，告诉编译器生成位置无关的代码。它的工作原理是这样的：
- 函数调用：通过全局偏移表（GOT）间接跳转
- 数据访问：通过GOT获取变量的实际地址
- 字符串常量：放在只读数据段，通过相对寻址访问
你可能会问：那-fPIC和-fpic有什么区别？
嗯，-fpic是-fPIC-fPIC，省心。
小提示：如果你在x86_64平台上编译，GCC默认就会生成PIC代码，因为x86_64架构本身就不支持非PIC的共享库。但在x86（32位）上，你必须显式指定-fPIC。
创建共享库的步骤
咱们直接上代码。假设我有两个源文件：math_ops.c和string_ops.c，想做成一个共享库。
第一步：编译成目标文件，加-fPIC
gcc -c -fPIC math_ops.c -o math_ops.o
gcc -c -fPIC string_ops.c -o string_ops.o第二步：链接成共享库
gcc -shared -o libmylib.so math_ops.o string_ops.o -lm这里-shared告诉链接器生成共享库，-o libmylib.so指定输出文件名。注意命名规范：lib开头，.so结尾。
第三步：使用共享库
gcc main.c -L. -lmylib -o myprogram-L.告诉链接器在当前目录找库，-lmylib链接libmylib.so。
注意：运行时，系统需要知道共享库的位置。你可以设置LD_LIBRARY_PATH环境变量，或者把库放到/usr/lib等标准路径下。我曾经因为忘了设置这个，程序启动时报"cannot open shared object file"，排查了半天才发现是路径问题。
不同平台上的差异
| 平台 | 共享库后缀 | 编译选项 | 加载方式 |
|---|---|---|---|
| Linux | .so | -fPIC, -shared | dlopen() / LD_LIBRARY_PATH |
| Windows | .dll | /DLL (MSVC) | LoadLibrary() |
| macOS | .dylib | -fPIC, -dynamiclib | dlopen() / DYLD_LIBRARY_PATH |
在Windows上用MinGW的话，命令跟Linux差不多：
gcc -c -fPIC math_ops.c -o math_ops.o
gcc -shared -o mylib.dll math_ops.omacOS上则是：
gcc -c -fPIC math_ops.c -o math_ops.o
gcc -dynamiclib -o libmylib.dylib math_ops.oPIC的内部机制
咱们用一张图来理解PIC是怎么工作的：
看到这张图你就明白了。主程序调用共享库里的函数时，不是直接跳过去，而是先查GOT表，拿到函数的实际地址，再跳转。GOT表是加载器在运行时填写的，所以共享库放在哪个地址都无所谓。
避坑指南
我这些年踩过的坑，总结一下：
- 忘记加
-fPIC：在x86上编译共享库，不加-fPIC会报错。在x86_64上虽然默认加了，但养成习惯总没错。 - 库的命名不规范：Linux上共享库必须叫
libxxx.so，否则链接器找不到。我见过有人叫my.so，结果死活链接不上。 - 运行时找不到库：编译时用
-L指定路径，但运行时系统不知道库在哪。要么设LD_LIBRARY_PATH，要么把库装到系统目录。 - 符号冲突：两个共享库导出同名函数，程序调用时到底用哪个？嗯，这是个复杂问题，后面章节会详细讲。
我曾经在一个嵌入式项目里，为了省空间，编译共享库时没加-fPIC。结果程序在开发板上跑得好好的，换到另一块板子上就段错误。查了两天，最后发现是地址冲突。从那以后，我编译共享库必加-fPIC，哪怕是在x86_64上。
总结
共享库的核心就是PIC。没有PIC，共享库就没办法在内存里随意移动，也就失去了“共享”的意义。-fPIC这个选项虽然小，但它是共享库的基石。你想想看，如果没有它，每个程序都得给共享库分配固定的地址，那还怎么共享？
创建共享库的步骤其实很简单：编译加-fPIC，链接加-shared。但背后的原理，值得你花时间好好理解。毕竟，搞C/C++的，不懂链接和加载，就像开车不懂发动机——能开，但心里没底。
公众号:蓝海资料掘金营，微信deep3321