GNU bug report logs - #50666
28.0.50; Fix native compilation on Cygwin

Previous Next

Package: emacs;

Reported by: Ken Brown <kbrown <at> cornell.edu>

Date: Sat, 18 Sep 2021 20:52:02 UTC

Severity: normal

Tags: patch

Found in version 28.0.50

Done: Ken Brown <kbrown <at> cornell.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: ASSI <Stromeko <at> nexgo.de>
Cc: 50666 <at> debbugs.gnu.org, kbrown <at> cornell.edu
Subject: bug#50666: 28.0.50; Fix native compilation on Cygwin
Date: Sun, 19 Sep 2021 10:08:24 +0300
> From: ASSI <Stromeko <at> nexgo.de>
> Cc: Ken Brown <kbrown <at> cornell.edu>,  50666 <at> debbugs.gnu.org
> Date: Sun, 19 Sep 2021 09:00:46 +0200
> 
> Eli Zaretskii writes:
> > Isn't there a way to rebase a DLL on the fly, when it is loaded?
> 
> There is (of course), but then there is no guarantee that you can do a
> fork from the resulting memory image.  Which is exactly the problem that
> fixing the base addresses of all DLL was intended to solve and has the
> unfortunate side effect that you need to modify the on-disk
> representation.  On 64bit, marking the eln as ASLR w/ high-entropy and
> large address aware will probably work most of the time, but 32bit is
> much more prone to collisions (in fact I did use a shell inside an X11
> Emacs as my test case when I last unsuccessfully tried to make ASLR work
> for Cygwin).

So this basically means that native-compilation is unworkable for
32-bit Cygwin, right?




This bug report was last modified 3 years and 295 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.