Linux 编译失败并显示“制作共享对象时无法使用针对 `.rodata.str1.8' 的重定位 R_X86_64_32”
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/19364969/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Compilation fails with "relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object"
提问by user1667191
I'm trying to compile this source code from the makefile in a VPS, but its not working. The VPS is a 64 Cent OS
我正在尝试从 VPS 中的 makefile 编译此源代码，但它不起作用。VPS 是一个 64 美分的操作系统
Here's the full error
这是完整的错误
# 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
Here's my makefile:
这是我的生成文件：
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
Anyone know what's wrong?
有谁知道怎么了？
采纳答案by Alexander Shukaev
Do what the compiler tells you to do, i.e. recompile with -fPIC. To learn what does this flag do and why you need it in this case, see Code Generation Optionsof the GCC manual.
做编译器告诉你做的事情，即使用-fPIC. 要了解此标志的作用以及在这种情况下为什么需要它，请参阅GCC 手册的代码生成选项。
In brief, the term position independent code(PIC) refers to the generated machine code which is memory address agnostic, i.e. does not make any assumptions about where it was loaded into RAM. Only position independent code is supposed to be included into shared objects (SO) as they should have an ability to dynamically change their location in RAM.
简而言之，术语位置无关代码(PIC) 是指生成的机器代码，它与内存地址无关，即不对其加载到 RAM 的位置进行任何假设。只有位置无关代码应该包含在共享对象 (SO) 中，因为它们应该能够动态更改它们在 RAM 中的位置。
Finally, you can read about it on Wikipediatoo.
最后，你也可以在维基百科上阅读它。
回答by EIIPII
It is not always about the compilation flags, I have the same error on gentoo when using distcc.
这并不总是关于编译标志，我在使用 distcc 时在 gentoo 上有同样的错误。
The reason is that on distcc server is using a not-hardened profile and on client the profile is hardened. Check this discussion: https://forums.gentoo.org/viewtopic-p-7463994.html
原因是在 distcc 服务器上使用的是未强化的配置文件，而在客户端上配置文件是强化的。检查此讨论：https: //forums.gentoo.org/viewtopic-p-7463994.html
回答by XavierStuvw
In my case this error occurred because a makecommand was expecting to fetch shared libraries (*.sofiles) from a remote directory indicated by a LDFLAGSenvironment variable. In a mistake, only static libraries were available there (*.laor *.afiles).
在我的情况下，发生此错误是因为make命令希望*.so从LDFLAGS环境变量指示的远程目录中获取共享库（文件）。错误的是，那里只有静态库（*.la或*.a文件）可用。
Hence, my problem did not reside with the program I was compiling but with the remote libraries it was trying to fetch.
So, I did not need to add any flag (say, -fPIC) to the compilation interrupted by the relocation error.
Rather, I recompiled the remote library so that the shared objects were available.
因此，我的问题不在于我正在编译的程序，而在于它试图获取的远程库。因此，我不需要向-fPIC被重定位错误中断的编译添加任何标志（例如，）。相反，我重新编译了远程库，以便共享对象可用。
Basically, it's been a file-not-found error in disguise.
基本上，这是一个伪装的文件未找到错误。
In my case I had to remove a misplaced --disable-sharedswitch in the configureinvocation for the requisite program, since shared and static libraries were both built as default.
在我的情况下，我必须删除必需程序调用中错位的--disable-shared开关configure，因为共享库和静态库都是默认构建的。
I noticed that most programs build both types of libraries at the same time, so mine is probably a corner case. In general, it may be the case that you rather have to enable shared libraries, depending on defaults.
我注意到大多数程序同时构建两种类型的库，所以我的可能是一个极端情况。通常情况下，您可能更愿意启用共享库，具体取决于默认设置。
To inspect your particular situation with compile switches and defaults, I would read out the summary that shows up with ./configure --help | less, typically in the section Optional Features. I often found that this reading is more reliable than installation guides that are not updated while dependency programs evolve.
要使用编译开关和默认值检查您的特定情况，我会读出带有 的摘要./configure --help | less，通常在可选功能部分。我经常发现这种阅读比在依赖程序发展时不更新的安装指南更可靠。
回答by Saurav Chowdhury
I had the same problem. Try recompiling using -fPICflag.
我有同样的问题。尝试使用-fPIC标志重新编译。
回答by Gábor Kiss-Vámosi
A "clean" solved it for me.
“干净”为我解决了这个问题。
My project is a C++ application (not shared library). I randomly got this error after a lot of successful builds.
我的项目是一个 C++ 应用程序（不是共享库）。在多次成功构建后，我随机收到此错误。
回答by Pedro H
Fixed it with -no-pieoption in linker stage:
-no-pie在链接器阶段使用选项修复它：
g++-8 -L"/home/pedro/workspace/project/lib" -no-pie ...
