Stefano Bonifazi <stefboombastic@xxxxxxxxx> 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
