问题
I'm porting a shared library from 32-bit to 64-bit. It's composed of some assembly (written for NASM) that exports several procedures and a little bit of higher-level C glue code. I'm building on a 64-bit Debian machine with NASM 2.10.01 and GNU ld 2.22.
Having fixed all the push/pop issues (pushing 32-bit parts of registers obviously won't work in 64-bit mode), I've got the object to assemble, but now I'm halted by the linking stage. Here are my command lines - assembly:
nasm -Ox -dPTC_ARCH=X64 -f elf64 particl.asm -o particlasm.o
Linking:
ld -shared -lc -S -melf_x86_64 particlasm.o ptc_highlevel.o -o libparticlasm.so
(the -lc switch enforces linking the standard C library in - I need some of its functions in the assembly code)
However, the linker fails with the following message:
ld: particlasm.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC
particlasm.o: could not read symbols: Bad value`
I'm aware of why PIC is required on 64-bit systems; thing is, I am indeed using PIC as described in section 9.2 of the NASM manual. However, it appears to me that NASM is somehow not marking my code as PIC in the ELF symbol table, which causes the linker to protest, and I cannot find any related command-line switches or directives in the manual to fix this.
Any ideas?
回答1:
I've solved it! In my case the relocations resulted from:
1) libc calls, which I solved by appending wrt ..plt to libc calls, e.g. call rand wrt ..plt,
2) references to constants placed within the code, which needed to change from e.g. push MASK_RGB to push ptr [rel MASK_RGB] (where ptr is my own type that aliases to the native word type for the given platform).
来源：https://stackoverflow.com/questions/11916394/cant-link-a-shared-library-from-an-x86-64-object-from-assembly-because-of-pic