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

[Ian Lance Taylor <iant at google dot com>]

"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.


> 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