Amd64 relocation R_X86_64_32S in a static lib

Mark Kettenis mark.kettenis at
Tue Nov 5 22:49:04 CET 2013

> From: nisse at (Niels =?iso-8859-1?Q?M=F6ller?=)
> Date: Tue, 05 Nov 2013 15:39:35 +0100
> Torbjorn Granlund <tg at> writes:
> > Now we have (at least) two OpenBSD ABIs for AMD64, pre 5.3 and now 5.3,
> > 5.4.  To make sense of things, I would not be surprised to see
> > R_X86_64_64 banned from 5.5 and on, creating a 3rd OpenBSD AMD64 ABI.
> I don't understand the fine details of which reloc types make sense in
> pic code, but if I understand Philip correctly, the main problem is not
> a ABI change, but changed compiler default. And then you get link errors
> when linking together pic objects created by the compiler, with non-pic
> objects created from the gmp assembly files.

Not really.  The problem is linking non-pic objects created from the
gmp assembly files into a position-independent executable.  And this
is in fact very similar to the problems you get when you try to link
non-pic objects into a shared library.

> I think you'd get similar problems as if a user configures gmp with,
> e.g., --disable-shared CFLAGS=-fpic. Do you agree with this analysis?

Well, linking pic objects into an executable will work on all common
ELF platforms.  So to reproduce the problem on platforms that have
traditional position-dependent executables, you'd have to configure
with something like:

  --disable-shared CFLAGS=-fpic LDFLAGS=-Wl,-pie



More information about the gmp-devel mailing list