我知道共享库需要-fPIC并知道原因。
但是，我不清楚这个问题：
在构建可执行文件或静态库期间是否永远不会使用-fPIC？
答案 0 :(得分：4)
在构建可执行文件或静态库期间是否永远不会使用
-fPIC？
永远不是一个强硬的词，上面的陈述是错误的。
使用-fPIC构建的代码（略微）不是最优的，那么为什么要将它放入除共享库之外的任何其他内容？
让我们从一个静态库开始，它有一个简单的答案。
假设您想为用户提供一个静态库，可以将 可执行文件，或链接到他们自己的共享库中？
在这种情况下，你必须给它们3个独立的归档库（一个用-fPIC构建，用于链接到共享库，一个用-fPIE构建，用于链接到PIE可执行文件，和＃34;常规＆＃34; one），或者你可以给他们一个归档库（必须使用-fPIC构建代码）。
现在，可以说你应该给他们一个共享库，但这会迫使你的最终用户分发2个二进制文件，他们可能不愿意这样做。
但是假设您要构建常规（非PIE）可执行文件。将-fPIC代码链接到这样的可执行文件中的原因是什么？
好吧，假设您处于开发阶段，并且还不关心如何优化代码。进一步假设您要将代码测试为共享库，和作为PIE和非PIE可执行文件的一部分。
在上述条件下，您可以编译代码3次（使用和不使用-fPIC，使用-fPIE），或，您可以编译一次（使用{ {1}}）并将其链接到所有3个共享库，PIE和非PIE可执行文件。这样做可以节省大量的编译时间，有些还可以构建系统复杂性。
TL; DR：将-fPIC个对象放入可执行文件中，静态库就有了它的位置，你应该理解为什么要这样做（如果你最终这样做了）。
<强>更新
目标文件中的代码始终是可重定位的
正确。
它是与位置无关的代码吗？
否：并非所有可重定位代码都与位置无关。
与位置无关的代码是可重定位代码的子集。可重定位代码可以具有适用于任何部分的重定位。与位置无关的代码必须不对-fPIC（和.text）进行任何重定位。