Home/ Questions/Q 6712779
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T08:17:59+00:00

Trying to compile non-PIC code into a shared library on x64 with gcc results

  • 0

Trying to compile non-PIC code into a shared library on x64 with gcc results in an error, something like:

/usr/bin/ld: /tmp/ccQ2ttcT.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC

This question is about why this is so. I know that x64 has RIP-relative addressing which was designed to make PIC code more efficient. However, this doesn’t mean load-time relocation can’t be (in theory) applied to such code.

Some online sources, including this one (which is widely quoted on this issue) claim that there’s some inherent limitation prohibiting non-PIC code in shared libs, because of RIP-relative addressing. I don’t understand why this is true.

Consider “old x86” – a call instruction also has an IP-relative operand. And yet, x86 code with call in it compiles just fine into a shared lib without PIC, but using the load-time relocation R_386_PC32. Can’t the same be done for the data RIP-relative addressing in x64?

Note that I fully understand the benefits of PIC code, and the performance penalty RIP-relative addressing helps alleviate. Still, I’m curious about the reason for not allowing using non-PIC code. Is there a real technical reasoning behind it, or is it just to encourage writing PIC code?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Here is the best explanation I’ve read from a post on comp.unix.programmer:

    Shared libs need PIC on x86-64, or more accurately, relocatable code
    has to be PIC. This is because a 32-bit immediate address operand
    used in the code might need more than 32 bits after relocation. If
    this happens, there is nowhere to write the new value.

    • 0