Strange problem linking object files, static and dynamic libs into a single shared library on x86_64 platform (Linux 2.6, AMD)

[Dr. David Kirkby]

On 10/23/10 01:46 AM, Ian Lance Taylor wrote:
> "Sören Gerlach"<soeren.gerlach@gmx.de>  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.

Although this is reported against linux, this sort of problem is not unknown on 
Solaris, and is a cause of all manner of ills. One compiles a load of C files 
with the -fPIC flag, then tries to created a shared library, and find the 
library causes problems with 'relocation' issues.

I can think of two programs which build shared libraries with text relocation 
problems. This does not cause a major problem on 32-bit code, but does on 64-bit 
code.

In both cases, compiling the code with the Sun compiler, rather than gcc solves 
the problem.

The Lisp interpreter ECL
http://trac.sagemath.org/sage_trac/ticket/9840

and the statistics package R
http://trac.sagemath.org/sage_trac/ticket/9040
(It's for this very reason that the R developers have never been able to build a 
64-bit version of R on Solaris x86 using gcc - the R manual say you *must* use 
the Sun compiler and not gcc).

These are the only two issues that I'm aware of that prevent the Sage maths 
software building properly 64-bit on Solaris.

There's a discussion on this Sun blog about how to trac the offending file down

http://blogs.sun.com/rie/entry/my_relocations_don_t_fit

The blog assumes the Solaris operating system, though I suspect if you used the 
Linux command 'readelf' instead of the Solaris one 'elfdump' one could probably 
achieve the same results.

However, solving this looks non-trivial. It will certainly require carefully 
hunting trough some very large files and taking ones time over it. I've been 
putting this job off for some time!

Dave