Thanks -----Original Message----- From: Andrew Haley [mailto:aph@xxxxxxxxxx] Sent: Wednesday, December 16, 2009 5:27 PM To: Alexey Skidanov Cc: gcc-help@xxxxxxxxxxx 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@xxxxxxxxxx] > Sent: Wednesday, December 16, 2009 4:58 PM > To: Alexey Skidanov > Cc: gcc-help@xxxxxxxxxxx > 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.
