Compilation fails with "relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object"

Question

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

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?

Sorry but I'm not sure how to do this. Can't find anything about "-fPIC" on google. — user1667191, Oct 14 '13 at 16:49
Try something like `COMPILE_FLAGS=-c -O3 -w -DLINUX -fPIC -I../SDK/amx/` — Joachim Isaksson, Oct 14 '13 at 17:05
Related: http://stackoverflow.com/questions/6093547/what-does-r-x86-64-32s-relocation-mean — Ciro Santilli OurBigBook.com, Oct 22 '15 at 20:16
if you search google for -fPIC you will certainly find nothing. Remove the minus or use quotation marks "-fPIC" otherwise you omit all results containing fPIC. — d00d, Jul 07 '17 at 07:49
Possible duplicate of [What do R\_X86\_64\_32S and R\_X86\_64\_64 relocation mean?](https://stackoverflow.com/questions/6093547/what-do-r-x86-64-32s-and-r-x86-64-64-relocation-mean) — jww, Oct 23 '17 at 19:21

Alexander Shukaev · Accepted Answer · 2013-10-14T17:13:57.523

131

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 Options of the GCC manual.

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.

Finally, you can read about it on Wikipedia too.

edited Oct 14 '13 at 17:13

answered Oct 14 '13 at 17:05

Alexander Shukaev

16,674
8
70
85

5

Could you explain how to recompile with -fPIC? – Beni Bogosel Sep 10 '14 at 18:10
16

@Beni Bogosel: This is very simple. You just add the `-fPIC` to all the compiler invocations for all the source files (translation units, e.g. `*.cpp` files) of the library. The concrete way of doing that depends on the build system that you use. For instance, in CMake you could issue `set_target_properties(${LIBRARY_NAME} PROPERTIES POSITION_INDEPENDENT_CODE ON)`. In case of this guy (using plain old Make), he would have to do `COMPILE_FLAGS+=-fPIC` since he is using this variable to denote the set of compilation flags for all the source files of his library. – Alexander Shukaev Sep 11 '14 at 06:46
1

to enable -fPIC using configure: configure --enable-shared, see https://stackoverflow.com/a/850464/440403 – camino Jan 26 '19 at 03:05

XavierStuvw · Answer 2 · 2017-07-07T06:38:17.473

57

In my case this error occurred because a make command was expecting to fetch shared libraries (*.so files) from a remote directory indicated by a LDFLAGS environment variable. In a mistake, only static libraries were available there (*.la or *.a files).

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.

Basically, it's been a file-not-found error in disguise.

In my case I had to remove a misplaced --disable-shared switch in the configure invocation for the requisite program, since shared and static libraries were both built as default.

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.

edited Jul 07 '17 at 06:38

answered Feb 22 '17 at 09:54

XavierStuvw

1,294
2
15
30

2

Perfect, "it's been a file-not-found error in disguise." In my case the dependency was not installed yet. – Litty Apr 09 '17 at 08:51
+1 In my case, a newer copy of openssl was built manually and installed without shared libraries. The library I was trying to build was already compiled with -fPIC. Is there anyway that the compiler could recognize this error to give a less obscure error message, for example "Expected to find shared library libssl.so, but only found incompatible static library /usr/local/ssl/lib/libssl.a." ? – Rohan Mahy Jul 11 '17 at 03:36
1

Thanks. I had a make -j and parallel execution was not allowed for this software package. – MikeBergmann Jun 13 '18 at 08:39
In my case, I have this line "find_library(NGHTTP2_LIB NAMES libnghttp2.a libnghttp2.so libnghttp2.dylib)". and it was only picking up the .a one, I later changed it to find_library(NGHTTP2_LIB NAMES libnghttp2.so libnghttp2.a libnghttp2.dylib)" and it started working. My concern is, what it use to work before for me? – Nabz C Apr 29 '20 at 06:49
1

@NabaChinde I am afraid I do not have an answer for your question also because I lack context information on your outcomes. I would certainly encourage to post a separate question in which you explain your working situation and the unexpected behaviour. – XavierStuvw Apr 29 '20 at 08:48

score 20 · Answer 3 · answered Jul 24 '19 at 10:59

20

Fixed it with -no-pie option in linker stage:

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

answered Jul 24 '19 at 10:59

pedromorfeu

1,739
14
18

This was all I needed to get successful compilation as well – KhanKhuu Jun 20 '22 at 19:22

score 11 · Answer 4 · answered Sep 12 '15 at 21:50

It is not always about the compilation flags, I have the same error on gentoo when using distcc.

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

Gábor Kiss-Vámosi · Answer 5 · 2020-07-18T18:08:46.283

4

Simply cleaning the project solved it for me.

My project is a C++ application (not a shared library). I randomly got this error after a lot of successful builds.

edited Jul 18 '20 at 18:08

answered Aug 20 '18 at 07:38

Gábor Kiss-Vámosi

488
5
14

score 2 · Answer 6 · edited Apr 30 '18 at 07:01

2

I had the same problem. Try recompiling using -fPIC flag.

edited Apr 30 '18 at 07:01

Samuel Liew

76,741
107
159
260

answered Apr 30 '18 at 05:36

Saurav Chowdhury

31
2

score 0 · Answer 7 · answered Jul 04 '20 at 08:07

I'm getting the same solution as @camino's comment on https://stackoverflow.com/a/19365454/10593190 and XavierStuvw's reply.

I got it to work (for installing ffmpeg) by simply reinstalling the whole thing from the beginning with all instances of $ ./configure replaced by $ ./configure --enable-shared (first make sure to delete all the folders and files including the .so files from the previous attempt).

Apparently this works because https://stackoverflow.com/a/13812368/10593190.

score 0 · Answer 8 · answered Feb 14 '22 at 16:01

0

We had the same problem. It turned out to be a mix-up in a Makefile. The error occurred when the linker was gcc, but the C++ compiler clang++. Changing the linker to clang++ fixed it.

answered Feb 14 '22 at 16:01

Ralf

1,203
1
11
20

MURUGESAN N · Answer 9 · 2023-04-05T02:30:55.340

I know that this query was asked a year ago. I tried the given error at my system. I tried simulating the given error using Make file providing this error. Error Make file(each line begins using a tab instead of multiple spaces):

all:
    @echo "/usr/bin/gcc -c -O3 -w -DLINUX -I../SDK/amx/ ../SDK/amx/*.c";\
    /usr/bin/gcc -c -O3 -w -DLINUX -I../SDK/amx/ ../SDK/amx/*.c;\
    echo "/usr/bin/g++ -c -O3 -w -DLINUX -I../SDK/amx/ ../SDK/*.cpp";\
    /usr/bin/g++ -c -O3 -w -DLINUX -I../SDK/amx/ ../SDK/*.cpp;\
    echo "/usr/bin/g++ -c -O3 -w -DLINUX -I../SDK/amx/ *.cpp";\
    /usr/bin/g++ -c -O3 -w -DLINUX -I../SDK/amx/ *.cpp;\
    echo "/usr/bin/g++ -O2 -shared -o "TCP_V1.so" *.o";\
    /usr/bin/g++ -O2 -shared -o "TCP_V1.so" *.o

Error:

  /usr/bin/gcc -c -O3 -w -DLINUX -I../SDK/amx/ ../SDK/amx/*.c
  /usr/bin/g++ -c -O3 -w -DLINUX -I../SDK/amx/ ../SDK/*.cpp
  /usr/bin/g++ -c -O3 -w -DLINUX -I../SDK/amx/ *.cpp
  /usr/bin/g++ -O2 -shared -o TCP_V1.so *.o
  /usr/bin/ld: one.o: relocation R_X86_64_32 against `.rodata.str1.1'
  can not be used when making a shared object; recompile with -fPIC
  one.o: error adding symbols: Bad value
  collect2: error: ld returned 1 exit status

Updated Make file:

all:
      @echo "/usr/bin/gcc -fPIC -c -O3 -w -DLINUX -I../SDK/amx/ ../SDK/amx/*.c";\
      /usr/bin/gcc -fPIC -c -O3 -w -DLINUX -I../SDK/amx/ ../SDK/amx/*.c;\
      echo "/usr/bin/g++ -fPIC -c -O3 -w -DLINUX -I../SDK/amx/ ../SDK/*.cpp";\
      /usr/bin/g++ -fPIC -c -O3 -w -DLINUX -I../SDK/amx/ ../SDK/*.cpp;\
      echo "/usr/bin/g++ -fPIC -c -O3 -w -DLINUX -I../SDK/amx/ *.cpp";\
      /usr/bin/g++ -fPIC -c -O3 -w -DLINUX -I../SDK/amx/ *.cpp;\
      echo "/usr/bin/g++ -O2 -shared -o "TCP_V1.so" *.o";\
      /usr/bin/g++ -O2 -shared -o "TCP_V1.so" *.o

Compilation fails with "relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object"

9 Answers9

Linked

Related