Amd64 relocation R_X86_64_32S in a static lib

Niels Möller nisse at
Tue Nov 5 22:20:46 CET 2013

Torbjorn Granlund <tg at> writes:

> If one tries to assemble and link the former code on a 5.3/5.4 system,
> one gets again the error "relocation R_X86_64_32S can not be used when
> making a shared object; recompile with -fPIC".

What other objects were involved in the link? I guess something like
crt.o was compiled as non-pic on pre-5.3 systems, but as pic-code on
5.3? I'd like to know if the problem is that the linker input files are
an somehow incompatible mix of pic and non-pic objects, or if the
problem is is that by default the linker insists on creating a "position
independent executable" (PIE).

> I'd call this an ABI change since code valid under the AMD64 ELF ABI as
> well as on older OpenBSD releases is no longer supported.

If you move an *executable* from pre-5.3 to 5.3, it might still work
fine, if non-position-independent-executables are still supported, and
compatible crt.o and the like are included in the executable.

It's very clear that the ABI-spec defines which executables and shared
libraries are valid, but I imagine one could have a long
flamewa^H^H^H^H^H^Hdebate on whether or not the ABI really specifies
which object files and static libraries are valid when used with the
default compiler settings. But in any case, it's going to be
inconvenient for users if static libraries can't be copied over to a
later OS release.

> (There are pros and cons with feature tests, though.  I consider the
> free software OSes out there to be primary targets for GMP, and I'd like
> to avoid creating GMP objects that cannot be moved between FooBSD x.y
> and FooBSD x.y+k.

I think it would be a good test to compile gmp on pre-5.3, and use that
library when compiling and linking some simple program on openbsd-5.3.
Trying both with a static and a shared gmp library. And maybe trying
also with --disable-assembly.

If any of that fails, that's clearly demonstrates some type of ABI

I'd also like to see the motivation for the discontinued support for

        movl    $17, %edi
        call    *jumptab(,%rax,8)

Which seems to be a very sensible thing to use in pic code. Offsets
between text and data segment are usually known at link time. Does
openbsd use some flavor of address space randomization which adds a
random load-time offset between .text and .data?


Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

More information about the gmp-devel mailing list