-fPIC仅用于共享库吗？ [英] Is -fPIC for shared libraries ONLY?

问题描述

我知道 -fPIC 对于共享库是必需的，并且知道为什么。

I know -fPIC is necessary for shared libraries and know why.

但是，我不清楚问题：

在构建可执行文件或静态库时，永远不要使用 -fPIC 吗？

Should -fPIC never be used during building an executable or a static library?

推荐答案

应该 -fPIC 在构建可执行文件或静态库时从未使用过？

Should -fPIC never be used during building an executable or a static library?

从来都不是一个强词，上面的陈述是错误的。

Never is a strong word, and the statement above is false.

用 -fPIC 生成的代码不是（略）最佳，所以为什么要将它放入任何东西除了共享库以外？

Code built with -fPIC is (slightly) less optimal, so why would you want to put it into anything other than a shared library?

让我们从一个静态库开始，它有一个简单的答案。

Let's start with a static library, which has an easy answer.

假设您想为您的用户提供一个静态库，该库可以链接到 可执行文件，或到自己的共享库中？

Suppose you want to give your users a static library that can be linked into either an executable, or into a shared library of their own?

在这种情况下，您必须要么给他们3个单独的ar细香葱的库（一个使用 -fPIC 构建的链接到共享库，一个使用 -fPIE 构建的链接到PIE可执行文件的库，以及一个常规库），也可以给他们一个存档库（必须具有使用 -fPIC 构建的代码）。

In that case you must either give them 3 separate archive libraries (one built with -fPIC for linking into shared libraries, one built with -fPIE for linking into PIE executables, and a "regular" one), or you can give them a single archive library (which must have code built with -fPIC).

现在，可以争辩说，您应该给他们一个共享库，但这会迫使最终用户分发2个二进制文件，而他们可能不愿意这样做。

Now, it could be argued that you should instead give them a shared library, but that forces your end users to distribute 2 binaries, and they may prefer to not do that.

但是假设您要构建一个常规（非PIE）可执行文件。将 -fPIC 代码链接到此类可执行文件的原因可能是什么？

But suppose you want to build a regular (non-PIE) executable. What could be the reason to link in -fPIC code into such executable?

那么，假设您在开发阶段，现在还不太在乎优化代码。进一步假设您想将代码作为共享库（和）作为PIE和非PIE可执行文件的一部分进行测试。

Well, suppose you are in the development stage, and don't care that much about optimizing the code yet. Suppose further that you want to test your code as both a shared library, and as part of PIE and non-PIE executable.

在上面条件下，您可以编译3次代码（使用和不使用 -fPIC ，以及使用 -fPIE ），或，您可以编译一次（使用 -fPIC ），并将其链接到共享库，PIE和非PIE可执行文件的全部3个中。这样做可以节省大量的编译时间，并节省一些构建系统的复杂性。

Under above conditions, you could either compile your code 3 times (with and without -fPIC, and with -fPIE), or you could compile it once (with -fPIC) and link it into all 3 of shared library, PIE and non-PIE executable. Doing this saves a lot of compilation time, and some build system complexity.

TL; DR：将 -fPIC 对象放入可执行文件和静态库中有其位置，您应该了解执行此操作的原因（如果最终执行此操作）。

TL;DR: putting -fPIC objects into executables and static libraries has its place, and you should understand the reason why you are doing it (if you end up doing it).

更新：

对象文件中的代码始终可重定位

Code in an object file is always relocatable

正确。

它是位置无关的代码吗？

is it position-independent code?

否：并非所有可重定位代码都是与位置无关的。

No: not all relocatable code is position-independent.

与位置无关的代码是子集可重定位代码。可重定位代码可以具有适用于 any 部分的重定位。与位置无关的代码必须不对 .text （和 .rodata ）有任何重定位。

Position-independent code is a subset of relocatable code. Relocatable code can have relocations that apply to any section. Position-independent code must not have any relocations against .text (and .rodata).

这篇关于-fPIC仅用于共享库吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！