Philip Guenther guent...@gmail.com writes:
Ah, but you are, sorta. In OpenBSD 5.3, platforms where the compiler and
toolchain support were for robust for it were switched to build PIE
objects and executables by default. So yes, that object _is_ expected to
be position independent.
Torbjorn Granlund t...@gmplib.org 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
On Tue, 5 Nov 2013, Torbjorn Granlund wrote:
Philip Guenther guent...@gmail.com writes:
Ah, but you are, sorta. In OpenBSD 5.3, platforms where the compiler and
toolchain support were for robust for it were switched to build PIE
objects and executables by default. So yes, that
Torbjorn Granlund t...@gmplib.org 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
Philip Guenther guent...@gmail.com writes:
That's bad. But then why not allow R_X86_64_32S too?
Because there's no guarantee that the target is within 2GB, as the
reference may resolve to the symbol in a different shared object which is
too far away.
Can you use ELF visibility to provide
