bug#18784: Coultdn't compile emacs-24.4

[Ulrich Mueller]

>>>>> On Mon, 16 Mar 2015, Eli Zaretskii wrote:

>> I guess if PIE is used in order to place Emacs's code at randomized
>> addresses (different address every time an Emacs process is launched),
>> it can break the dump because our subr objects will end up with pointers
>> to addresses that aren't valid any more (might be other such problems,
>> but that's the first that comes to my mind).

> Then this is only an issue on systems where PIE == address
> randomization, isn't it?

That would be my guess too. Here are some gdb backtraces showing that
the problem occurs in unexelf.c:

   https://bugs.gentoo.org/494316#c13
   https://bugs.gentoo.org/526948#c9
   http://debbugs.gnu.org/13847#5

There is a long history of Emacs catching up with kernel hardening
in this area. It started with setting ADDR_NO_RANDOMIZE via Linux
personality(2), then setting the NORANDEXEC flag with paxctl(1) or
setfattr(1). Now it seems that we need -nopie in addition.
My impression is that these are all workarounds that don't address the
real issue.