这个问题问到点子上了——很多刚接触共享库编译的开发者都会被这两个选项搞混，我来一步步拆解清楚：

1. 为什么-shared不隐含-fPIC？ #

核心原因是编译和链接是完全独立的两个阶段：

• -fPIC是编译阶段的选项，它告诉编译器生成「位置无关代码（Position-Independent Code）」——这种代码不依赖固定的内存地址，能被加载到进程地址空间的任意位置都正常运行。
• -shared是链接阶段的选项，它告诉链接器把目标文件打包成共享库（.so文件）格式，而不是可执行文件或静态库。

gcc的设计理念是让编译和链接的职责分离，链接阶段的选项不会自动回溯影响编译阶段的行为。另外，有些老平台（比如32位x86）其实允许生成「位置相关」的共享库（不需要-fPIC），所以gcc没有强制把-shared和-fPIC绑定，给用户留了适配不同场景的灵活性。

2. -fPIC在链接阶段是不是必需的？ #

分平台看：

• 64位平台（比如x86_64）：完全必需。如果你的目标文件没加-fPIC编译，用-shared链接时会直接报错，比如类似这样：

  relocation R_X86_64_PC32 against symbol `foo' can not be used when making a shared object; recompile with -fPIC
  

  这是因为64位架构的内存模型决定了，共享库必须使用位置无关代码才能正常加载。
• 32位平台（比如x86）：不是强制必需，但非常不推荐。你可以不用-fPIC生成共享库，但这种库加载时需要动态重定位所有地址，不仅效率低，还可能触发某些内存权限问题，而且兼容性很差（比如没法被多个进程共享内存页）。

所以结论是：无论什么平台，都应该用-fPIC编译共享库的目标文件，这是标准且可靠的做法。

3. 到底该怎么写编译命令？ #

必须同时使用-fPIC和-shared，只是要注意阶段：

• 分开编译和链接的写法（推荐，适合多文件项目）：

  # 编译每个源文件为位置无关的目标文件
  g++ -c -fPIC module1.cpp -o module1.o
  g++ -c -fPIC module2.cpp -o module2.o
  # 链接所有目标文件为共享库
  g++ -shared module1.o module2.o -o libmylib.so
  

• 单文件直接编译链接的写法：

  g++ -fPIC -shared mylib.cpp -o libmylib.so
  

如果你只加-shared不加-fPIC，在64位平台上一定会失败；32位平台可能能成，但那是历史遗留的兼容行为，绝对不要依赖它。

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