编译失败并显示“在制作共享对象时无法使用针对 `.rodata.str1.8' 的重定位 R_X86_64_32”答案

【问题标题】：Compilation fails with "relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object"编译失败并显示“在制作共享对象时无法使用针对 `.rodata.str1.8' 的重定位 R_X86_64_32”
【发布时间】：2013-10-22 07:09:10
【问题描述】：

我正在尝试从 VPS 中的 makefile 编译此源代码，但它不起作用。 VPS 是 64 美分操作系统

这是完整的错误

# make
gcc -c -O3 -w -DLINUX -I../SDK/amx/ ../SDK/amx/*.c
g++ -c -O3 -w -DLINUX -I../SDK/amx/ ../SDK/*.cpp
g++ -c -O3 -w -DLINUX -I../SDK/amx/ *.cpp
g++ -O2 -fshort-wchar -shared -o "TCP_V1.so" *.o
/usr/bin/ld: TCP-LINUX_V1.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be     used when making a shared object; recompile with -fPIC
TCP-LINUX_V1.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [all] Error 1

这是我的生成文件：

GPP=g++
GCC=gcc
OUTFILE="TCP_V1.so"

COMPILE_FLAGS=-c -O3 -w -DLINUX -I../SDK/amx/

all:
    $(GCC) $(COMPILE_FLAGS) ../SDK/amx/*.c
    $(GPP) $(COMPILE_FLAGS) ../SDK/*.cpp
    $(GPP) $(COMPILE_FLAGS) *.cpp
    $(GPP) -O2 -fshort-wchar -shared -o $(OUTFILE) *.o

有人知道怎么回事吗？

【问题讨论】：

你试过recompile with -fPIC吗？
抱歉，我不知道该怎么做。在谷歌上找不到任何关于“-fPIC”的信息。
试试COMPILE_FLAGS=-c -O3 -w -DLINUX -fPIC -I../SDK/amx/
相关：stackoverflow.com/questions/6093547/…
如果你在 google 上搜索 -fPIC 你肯定什么也找不到。删除减号或使用引号“-fPIC”，否则将省略所有包含 fPIC 的结果。

标签： c++ linux gcc linker shared-libraries

【解决方案1】：

按照编译器告诉您的操作，即使用-fPIC 重新编译。要了解此标志的作用以及在这种情况下为什么需要它，请参阅 GCC 手册的 Code Generation Options。

简而言之，术语位置无关代码 (PIC) 是指生成的与内存地址无关的机器代码，即不对其加载到 RAM 的位置做出任何假设。只有与位置无关的代码才应该包含在共享对象 (SO) 中，因为它们应该能够动态更改其在 RAM 中的位置。

最后，您也可以在 Wikipedia 上了解它。

【讨论】：

你能解释一下如何用-fPIC重新编译吗？
@Beni Bogosel：这很简单。您只需将-fPIC 添加到库的所有源文件（翻译单元，例如*.cpp 文件）的所有编译器调用中。执行此操作的具体方法取决于您使用的构建系统。例如，在 CMake 中，您可以发出 set_target_properties(${LIBRARY_NAME} PROPERTIES POSITION_INDEPENDENT_CODE ON)。如果是这个人（使用普通的 Make），他必须使用 COMPILE_FLAGS+=-fPIC，因为他使用这个变量来表示他库中所有源文件的编译标志集。
使用configure启用-fPIC：configure --enable-shared，见stackoverflow.com/a/850464/440403

【解决方案2】：

在我的情况下，发生此错误是因为 make 命令期望从 LDFLAGS 环境变量指示的远程目录中获取共享库（*.so 文件）。错误地，那里只有静态库可用（*.la 或*.a 文件）。

因此，我的问题不在于我正在编译的程序，而在于它试图获取的远程库。因此，我不需要向因重定位错误中断的编译添加任何标志（例如，-fPIC）。相反，我重新编译了远程库，以便共享对象可用。

基本上，这是一个变相的file-not-found错误。

在我的例子中，我必须在必要程序的configure 调用中删除一个放错位置的--disable-shared 开关，因为共享库和静态库都是默认构建的。

我注意到大多数程序同时构建这两种类型的库，所以我的可能是一个极端情况。通常，您可能需要启用共享库，具体取决于默认设置。

要使用编译开关和默认值检查您的特定情况，我会读出带有./configure --help | less 的摘要，通常在“可选功能”部分中。我经常发现这种阅读比依赖程序发展时不更新的安装指南更可靠。

【讨论】：

完美，“这是一个伪装的文件未找到错误。”就我而言，尚未安装依赖项。
+1 在我的例子中，一个较新的 openssl 副本是手动构建的，并且在没有共享库的情况下安装。我试图构建的库已经用 -fPIC 编译过。无论如何，编译器是否可以识别此错误以提供不那么模糊的错误消息，例如“预期找到共享库 libssl.so，但只找到不兼容的静态库 /usr/local/ssl/lib/libssl.a。” ?
谢谢。我有一个 make -j 并且这个软件包不允许并行执行。
就我而言，我有这一行“find_library(NGHTTP2_LIB NAMES libnghttp2.a libnghttp2.so libnghttp2.dylib)”。它只是拿起.a，后来我把它改成了find_library(NGHTTP2_LIB NAMES libnghttp2.so libnghttp2.a libnghttp2.dylib)”，它开始工作了。我担心的是，它以前对我有用吗？
@NabaChinde 恐怕我也没有你的问题的答案，因为我缺乏关于你结果的背景信息。我当然会鼓励您发布一个单独的问题，您可以在其中解释您的工作情况和意外行为。

【解决方案3】：

在链接器阶段使用-no-pie 选项修复它：

g++-8 -L"/home/pedro/workspace/project/lib" -no-pie ...

【讨论】：

【解决方案4】：

这并不总是与编译标志有关，我在使用 distcc 时在 gentoo 上遇到了同样的错误。

原因是 distcc 服务器上使用的是未加固的配置文件，而客户端上的配置文件已加固。检查此讨论： https://forums.gentoo.org/viewtopic-p-7463994.html

【讨论】：

【解决方案5】：

简单地清理项目为我解决了它。

我的项目是一个 C++ 应用程序（不是共享库）。在多次成功构建后，我随机收到此错误。

【讨论】：

【解决方案6】：

我遇到了同样的问题。尝试使用-fPIC 标志重新编译。

【讨论】：

【解决方案7】：

我得到的解决方案与 @camino 对 https://stackoverflow.com/a/19365454/10593190 和 XavierStuvw's reply 的评论相同。

我让它工作（用于安装 ffmpeg），只需从头开始重新安装整个东西，将 $ ./configure 的所有实例替换为 $ ./configure --enable-shared（首先确保删除所有文件夹和文件，包括 .so 文件从之前的尝试）。

显然这是因为https://stackoverflow.com/a/13812368/10593190。

【讨论】：

【解决方案8】：

我们遇到了同样的问题。事实证明这是Makefile中的混淆。当链接器为gcc，但C++ 编译器clang++ 时发生错误。将链接器更改为clang++ 修复了它。

【讨论】：