fpic

I get this error when I do the make: relocation R_X86_64_32 against `vtable for Torch::MemoryDataSet' can not be used when making a shared object; recompile with -fPIC It says that I should recompile with the -fPIC option. I did that, adding the -fPIC option to CFLAGS and CXXFLAGS , but I still get the same error. Is there any way to solve this? I have seen that this problem is related with the use of a 64-bit machine, and it is true that I am using one. I had this problem quite a while back and if I remember correctly, the fix was moving the placement of -fPIC just after gcc in the command

I'm trying to install GHC with -fPIC support in Fedora. I've grabbed a source tarball since it seems no binary one has this. In Build.mk i've changed the quick build type to ifeq "$(BuildFlavour)" "quick" SRC_HC_OPTS = -H64m -O0 -fasm -fPIC GhcStage1HcOpts = -O -fasm -fPIC GhcStage2HcOpts = -O0 -fasm -fPIC GhcLibHcOpts = -O -fasm -fPIC SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif unfortunately, when compiling i still get the ld error ghc -fglasgow-exts --make -shared -oHs2lib.a /tmp/Hs2lib924498/Hs2lib.hs dllmain.o -static -fno

Consider this code: // foo.cxx int last; int next() { return ++last; } int index(int scale) { return next() << scale; } When compiling with gcc 7.2: $ g++ -std=c++11 -O3 -fPIC This emits: next(): movq last@GOTPCREL(%rip), %rdx movl (%rdx), %eax addl $1, %eax movl %eax, (%rdx) ret index(int): pushq %rbx movl %edi, %ebx call next()@PLT ## next() not inlined, call through PLT movl %ebx, %ecx sall %cl, %eax popq %rbx ret However, when compiling the same code with the same flags using clang 3.9 instead: next(): # @next() movq last@GOTPCREL(%rip), %rcx movl (%rcx), %eax incl %eax movl %eax, (%rcx)

I recently received a: ...relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC error while trying to compile a program as a shared library. Now the solution to this is not too difficult (recompile all dependencies with -fPIC), but after some research it turns out that this problem is only present on x86-64 platforms. On 32bit any position dependent code can still be relocated by the dynamic loader. The best answer I could find is: x86 has support for .text relocations (which is what happens when you have position-dependend code).

I am trying to compile a shared library in Linux using a Makefile created with Cmake, but running make I obtain the following error: Linking CXX shared library libcpp-lib.so /usr/bin/ld: /home/davide/Desktop/boost_1_55_0/stage/lib/libboost_system.a(error_code.o): relocation R_X86_64_32 against .rodata.str1.1 can not be used when making a shared object; recompile with -fPIC /home/davide/Desktop/boost_1_55_0/stage/lib/libboost_system.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [libcpp-lib.so] Error 1 make[1]: *** [CMakeFiles/cpp-lib.dir/all] Error 2 make

I have a project where I have one static library libhelper.a and another with my actual shared object library, libtestlib.so . My goal is to link libhelper.a into libtestlib.so . Is that possible on Linux/BSD? When I tried and created a test program I got the following errors: ./prog1:/usr/local/lib/libtestlib.so.1.0: undefined symbol '' My guess is that this is occurring because libhelper.a was not compiled with -fPIC while libtestlib.so was. What is the proper way to build programs that use shared libraries that also have dependancies on static libraries? Thanks! My goal is to link libhelper

I made a piece of code which consists in a dynamic library ( lib.c ), and a main executable ( main.c ). In both files I define a global variable named: int global . Not very smart but it's not the question. When I compile the dynamic library the -fPIC option seems mandatory: gcc lib.c -fPIC -shared -o lib.so otherwise I get: /usr/bin/ld: /tmp/ccpUvIPj.o: relocation R_X86_64_32 against '.rodata' can not be used when making a shared object; recompile with -fPIC When I compile the executable it is not. gcc main.c -fPIC -ldl gcc main.c -ldl Both work, but have different behaviours I can not

I have an embedded application which will have a bootloader which will decide to run 1 of two applications directly from internal flash. I am trying to make these apps position independent so that they both can be compiled for the same base address. There is no operating system, so no dynamic linker is available. So far I have tried building with -fpie option (using gcc) with not too much success. The function calls appear to be correct but the global data does not have the correct address. The locally defined global data seems to have it's address offset by the amount that the app is offset