"SÃren Gerlach" <soeren.gerlach@xxxxxx> writes: > I made sure that really all objects files going into the supporting libs have been compiled with "-fPIC", was able to verify this from the build logs. The same applies to the object files that also should be linked directly into the final artefact. However, when I do the final step, the shrinked down example looks like this > > /usr/bin/g++ -shared -o lib/libqle.so<<here is the list of my .o files>> > -L./3rdparty/alea/lib -Wl,-Bstatic -lenbw_gpfc<<now more static& dynamic libs > to come>> > > I get the error message: > > "relocation R_X86_64_32 against `a local symbol' can not/ /be used when > making a shared object; recompile with -fPIC" > > > > This is annyoing (sort of ,-)) as I made sure that .o files in > "enbw_gpfc" have been compiled with -fPIC. Either there is a bug or some object file has not been compiled with -fPIC. The error message doesn't tell you which object file it was? When I look at the linker source code it appears to report the object file. > Choosing another lib I get a > slightly changed error message: > > "relocation R_X86_64_32S against..." > > What is the difference with that "S" at the end...? It doesn't matter for your purposes. The S at the end means that the 32-bit value is to be sign extended to a 64-bit value, rather than zero extended. > Should be noted I use gcc 4.1.2. If your error message really does not include the object file name, then the first thing I would try would to upgrade to a new release of the GNU binutils. That should show you the object file name, so you can confirm that it was indeed compiled with -fPIC. If it was compiled with -fPIC, then the next thing I would try would be to upgrade to a new version of gcc. It's entirely possible that there was a bug in this area. Ian
