Thank you very much for Your answer!
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 ..
I've collected the outputs of readelf -r for all the files listed in the
linking process and I've uploaded them here:
http://cid-9d0dd0f6c6e22fe8.office.live.com/browse.aspx/Public/Developing/master-degree-project/Logs?uc=5
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?
Are those not PIC all "R_PPC_ADDR16_HA/R_PPC_ADDR16_LO pairs" ?
They are almost everywhere inside those .o !! What are magic symbols?
How to distinguish them?
I think I'll better return on your blog about linkers .. I have got a so
strict deadline that I could not study them properly..
Can you say for sure that one(or more) of those files is not PIC as it
should from my listings?
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?
Thank you very much!
Stefano B.
