Position Independent Code usage on x86-64

[Andrew Haley]

Alexey Skidanov wrote:
> Ok. Thanks.
> I don't really understand ALL technical details in a found link. Could
> you explain this briefly (or refer me to other sources).

Briefly:

I can't explain it simpler than that.
If you want to put code into a shared library, compile it PIC.


Andrew.


> -----Original Message-----
> From: Andrew Haley [mailto:aph@redhat.com] 
> Sent: Wednesday, December 16, 2009 4:58 PM
> To: Alexey Skidanov
> Cc: gcc-help@gcc.gnu.org
> Subject: Re: Position Independent Code usage on x86-64
> 
> Alexey Skidanov wrote:
> 
>> We ported our code to 64 bit (CentOS 5.2 64 bit). We have some static
>> library that linked with some shared library. In 32 bit version, the
>> shared library was successfully created. Trying to create it in with
> 64
>> bit version compiler, we get the error: 
>>
>> /usr/bin/ld: .//libstatic.a(static.o): relocation R_X86_64_32 against
>> `__gxx_personality_v0' can not be used when making a shared object;
>> recompile with -fPIC
>> .//libstatic.a: could not read symbols: Bad value
>> collect2: ld returned 1 exit status
>>
>> We also found that if static library is linked with shared library
> then
>> it should be compiled with -fPIC option. But if the static library is
>> linked with ELF executable it shouldn't.
> 
> It can be, but it's not absolutely nmecessary.
> 
>> The questions are:
>> 1. Does it make sense that we need to know about static library exact
>> usage? 
>> 2. Is there an option of gcc that "generate" backward compatible (with
>> 32 bit version) compilation/linking process? 
> 
> No.  You best option is always to link with the -fPIC option all code
> that
> may go into shared libraries.  It won't hurt 32-bit libraries, and it
> may
> save memory.
> 
>> We found some explanation here
>> http://www.technovelty.org/code/c/amd64-pic.html
> 
> That seems right.  What more do you need?
> 
> Andrew.