能否仅构建一次-fPIC目标文件，同时用于静态库与动态库？

可行性结论 #

完全可以用一次编译生成的带-fPIC参数的目标文件，同时打包为静态库libx.a和动态库libx.so。静态库本质是目标文件的归档集合，链接器对归档内的目标文件是否为PIC没有强制限制，只要目标文件符合平台的二进制格式规范即可。

潜在问题 #

• 运行性能损失：PIC代码为实现位置无关性，会引入全局偏移表（GOT）、过程链接表（PLT）这类间接寻址机制。当静态链接带PIC的目标文件到可执行文件后，相比非PIC的静态库，频繁访问全局变量或调用函数时会多一层间接跳转，带来轻微但可感知的性能开销。
• 静态库体积膨胀：PIC目标文件包含更多的重定位信息和GOT/PLT相关代码段，文件尺寸通常比非PIC目标文件大10%-30%左右，打包成静态库后整体体积会明显增加。
• 链接优化受限：链接器对PIC目标文件的跨模块优化会受到限制，比如无法对跨模块的函数调用做直接内联，或者某些常量折叠、地址优化无法生效，最终导致生成的可执行文件体积更大、性能不如用非PIC目标文件构建的静态库。
• 平台兼容性风险：主流Linux、macOS平台的工具链完全支持PIC目标文件的静态链接，但部分嵌入式或小众平台的编译器/链接器可能对PIC静态链接的支持不完善，可能出现链接错误、运行时崩溃等问题。
• 调试复杂度提升：PIC代码的调试信息中，变量和函数地址都是相对偏移而非绝对地址，调试时需要工具额外解析重定位信息，定位问题的难度相比非PIC代码有所上升。

内容的提问来源于stack exchange，提问作者nvn