为什么“R_X86_64_32不能在制作共享对象时使用”的CMake解决方案是x86_64特有的？答案

【问题标题】：Why is the CMake solution for "R_X86_64_32 can not be used when making a shared object" specific to x86_64?为什么“R_X86_64_32不能在制作共享对象时使用”的CMake解决方案是x86_64特有的？
【发布时间】：2014-07-29 09:12:23
【问题描述】：

我在为我的新玩具编译一些插件时遇到了这个错误（在 Linux 上的 gcc/g++ 上）：

relocation R_X86_64_32 制作共享对象时不能使用；用 -fPIC 重新编译

我基本了解why PIC is needed，但在 CMake 系统中，solution seems to be this：

IF (CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
    SET_TARGET_PROPERTIES (${PLUGIN_BASE_LIB} PROPERTIES COMPILE_FLAGS "-fPIC")
ENDIF (CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")

我不明白为什么这个解决方案是有条件的。

follow-up 似乎表明除了 32 位 Linux 之外，基本上应该在所有地方使用 -fPIC，这表明上述内容不可移植。

我应该始终使用 -fPIC 吗？会不会有什么不良影响？

${PLUGIN_BASE_LIB} 需要静态链接到主可执行文件，以及静态作为插件的各种共享库。

【问题讨论】：

我从来没有注意到设置 -fPIC 有任何问题，除了编译器和运行时需要做的工作最少。通常不是问题。
在 mingw 中使用 -fPIC 和 -Werror 可能会导致错误（我需要检查，现在不在 Windows 上）
@languitar -fPIC 引入了显着的性能损失，因为编译器不再能够内联和克隆函数（因为它假定它必须保留符号插入语义）。

标签： gcc cmake portability

【解决方案1】：

理想情况下，您希望构建两种版本的代码：一种用于主可执行文件，另一种用于库。第一个需要使用-fPIE（现代发行版中的默认设置）编译，第二个需要使用-fPIC。正如您所指出的，这不依赖于目标架构。

您可以仅使用-fPIC 编译一个版本，但随后主可执行文件将不是最佳的，因为-fPIC 强制编译器遵守符号插入规则，这大大限制了它优化代码的能力，例如内联和克隆函数。

【讨论】：