relocation R_X86_64_PC32 against symbol `_ZTVN9xxxxxE' can not be used when making a shared object;
Linux compiler dynamic link library, I get the following error message, very strange. After investigation, determine the problem is not the code itself
/usr/bin/ld: ./xxxxx.o: relocation R_X86_64_PC32 against symbol `_ZTVN9xxxxxE' can not be used when making a shared object; recompile with -fPIC makefile:49: recipe for target 'libxxxxx.so' failed /usr/bin/ld: 最后的链结失败: 错误的值 collect2: error: ld returned 1 exit status
Checked online or follow the prompts to add -fPIC
This probably means lack of translation parameters -fPIC
If you are MakeFile way, you can increase directly in gcc, note .o files are generated when to add, in the back also packaged into .so when, as follows:
$gcc-fPIC -c hello.c $gcc-fPIC -c main.c $gcc -shared -fPIC -o hello hello.o main.o
But I was so files compiled by the eclipse, also used with gcc g ++, is meant to add -fPIC
Solution:
1. Select the project, right-click and select Properties 2. C / C ++ Build - Settings - Tool Settings 3. :( increase -fPIC figure below, there are two, attention to the case, space)
Well, then recompiling, you can.
But cautious, you may find the Eclipse looks like there is an option to solve this problem. Figure:
Very strange, the hook is not useful here. I do not know what the reason.
Of course there is an argument looks like online configuration commands directly into the environment variable, you should be able to, so not every project change to change
Further reading: -fPIC (The following is an excerpt from the Internet, has been written in great detail)
PIC code is the work of the Independent position PIC to make changes to the code segment .so file sharing in the true sense if you do not add -fPIC, the code segment .so file is loaded, the data object referenced in the snippet needs relocation, the relocation will modify the contents of the code segment, which resulted in each code segment to use this .so file copy process will generate this code segment .so file in the kernel. each copy is different, depending on the .so file code and data position segment memory map. without fPIC the compiler so, according to the loading position again loaded relocation again (because it is not inside the code position independent code) If multiple applications are used in common, then they must maintain a copy of each program is the code for a so. (because so loaded position of each program is different, obviously these codes after the relocation is different, of course, can not share) we always use to generate so fPIC , also never used fPIC to generate a. when fPIC dynamic link can be said that basically does not matter, libc.so the same can not fPIC compiled, just so so must be loaded into the address space of the user program Redirect all entries. Therefore, do not fPIC compiled so is not always bad. If you meet the following four requirements / conditions: 1. The library may need to be updated frequently 2. The library requires a very high efficiency (especially those with many use the global amount) 3. the library is not great. 4. the basic library does not need to be shared by multiple applications if this parameter is not added after compiling shared libraries, can be used, it may be two reasons: 1: gcc option is enabled by default -fPIC 2: loader make your position-independent code From the GCC perspective, shared fPIC options should be included, but it does not seem so systems are supported, so it is best to explicitly add fPIC options. See below `-shared ' Produce A Shared Object Which CAN BE linked with the then OTHER Objects to form AN Executable. Not the this All Systems Support the Option. The For Predictable Results, you Also the Specify the MUST at The Same, the SET of Options that were Used to the Generate code ( -fpic ` ',` -fPIC', or Model suboptions) the when you the Specify the this the Option. (1) -fPIC use, will generate PIC code, .so requirements for the PIC, in order to achieve the purpose of dynamically linked, otherwise, can not be achieved dynamic link. non-PIC PIC code differs mainly in that different access global data, jump label of. An access global data such as a command, the situation is non-PIC: LD R3, var1 the PIC is in the form of: ld r3, var1-offset @ GOT, meaning that the local table index GOT var1-offset at the address value indicative of a load, i.e. 4 byte var1-offset @ GOT actually at var1 address. This address is only known at run time, is filled by a dynamic-loader (ld-linux.so) go. Another example jump label instructions non-PIC situation is: jump printf, which means calling printf. PIC is in the form of: jump printf-offset @ GOT, meaning GOT jump address table index indicated at printf-offset local to the execution of code at the address placed in .plt section, each of the external function corresponding to this code section, whose function is to call dynamic-loader (ld-linux.so) to find the address of the function (in this case the printf), which is then written to the address for the local table index GOT printf-offset, and while performing this function. In this way, the 2nd call printf and they will jump directly to the address of printf, without having to look up. GOT is a data section, a table, a few special modifications except when entry, the contents of each entry can be executed again; the PLT is a text section, is a section of the code, no need to modify the execution. Each target different mechanisms to achieve the PIC, but very much the same. For example, MIPS no .plt, but called .stub, function and .plt same. Visible, dynamic link execute very complex, longer than statically linked execution time; however, significant savings in size, PIC and Dynamic Link technology is a very important development in the history of a milestone in the computer. gcc manul above have said -fpic If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that -fpic does not work;. in that case, recompile with -fPIC instead ( The 8K are Maximums ON THESE the SPARC The m68k ON and 32K and the RS / 6000. NO SUCH limit of The 386 has.) -fPIC The target for the If Supported Machine, Independent EMIT-position code, Suitable for Dynamic Linking The ON and limit the any Avoiding size of the global offset table. This option makes a difference on the m68k, PowerPC and SPARC. Position-independent code requires special support, and therefore works only on certain machines. the key is Skip global offset table entry sizes inside GOT . intel processors 4 byte should be uniform, no problem. Due to the special requirements of the powerpc assembly code or machine code, it is branched into short term and long two kinds. -fpic To save memory, in which GOT reserved "short" length. The -fPIC is using a bigger jump items.
