This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Problem creating PIC executable
Stefano Bonifazi <stefboombastic@gmail.com> writes:
> On 02/22/2011 02:45 AM, Ian Lance Taylor wrote:
>>
>> readelf -d just dumps the .dynamic section. That is only meaningful for
>> an object file or a shared library. It doesn't tell you anything about
>> a .o file. The only way to tell whether a .o file was compiled with
>> -fPIC is to examine the relocations via readelf -r.
>>
> I thought an object file is a .o file ..
Yes, they are the same thing.
> Anyway I am very confused .. You know I am a beginner with these
> things.. if I reference, let's say a function that is implemented on
> another module from a c file, then it should contain some sort of
> "relocation information" needed for resolving at link time the
> symbol.. so how can I distinguish in those relocs listings this normal
> informations from what instead is caused by not PIC compilation?
You just have to know which relocations are compatible with PIC and
which are not.
> Are those not PIC all "R_PPC_ADDR16_HA/R_PPC_ADDR16_LO pairs" ?
I could be wrong, but I think that those relocs are not PIC.
> They are almost everywhere inside those .o !! What are magic symbols?
> How to distinguish them?
There is typically one magic symbol named something like
_GLOBAL_OFFSET_TABLE_.
> I didn't compile gcc myself.. I am simply using what Debian6 PowerPC
> installed during installation.. so if this is bugged, all those who
> have installed Debian6 PPC have a bugged one!
> What can I do? Is there a way to force gcc to create all PIC code when
> installing(or compiling) it?
On GNU/Linux it seems very odd to me that if you use -fPIC on the link
line that you get crtbegin.o rather than crtbeginS.o. Normally
crtbeginS.o is the version compiled with -fPIC.
Ian