Position Independent Code usage on x86-64

Position Independent Code usage on x86-64

[Alexey Skidanov]

Hi,

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.

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? 

We found some explanation here
http://www.technovelty.org/code/c/amd64-pic.html

Thank you in advance,
Alexey

Re: Position Independent Code usage on x86-64

[Andrew Haley]

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.

RE: Position Independent Code usage on x86-64

[Alexey Skidanov]

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).

Thank you,
Alexey  

-----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.

Re: 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.

RE: Position Independent Code usage on x86-64

[Alexey Skidanov]

Thanks

-----Original Message-----
From: Andrew Haley [mailto:aph@redhat.com] 
Sent: Wednesday, December 16, 2009 5:27 PM
To: Alexey Skidanov
Cc: gcc-help@gcc.gnu.org
Subject: Re: Position Independent Code usage on x86-64

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.