Re: Heads up: Recent status: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Thu, 2016-12-08 at 14:47 +0100, Richard Braun wrote:
> On Thu, Dec 08, 2016 at 10:44:09AM +0100, Svante Signell wrote:
> > Since a long time emacs FTBFS due to unknown reasons. The latest version
> > building was Debian 24.5+1-5, from 28 Nov 2015.
> 
> As already mentioned, the real issue is in Emacs. See the relevant
> LWN article [1] for details.

I've read it, thanks! I think emacs is in a similar situation as Hurd with
respect to the still missing mlockall/munlockall functions.

> > Even before successful builds were by pure luck. One suspicious issue is
> > that emacs use sbrk() for memory allocation, right? Notably sbrk() is not
> > fool-proof as implemented for Hurd in glibc: Is it or is it not?
> 
> No it's not. And this is the real point I want to make in this message.
> 
> For performance reasons, the implementation of virtual memory maps
> was changed in GNU Mach [2]. 

> GNU Mach
> used to implement a bottom-up policy prior to this change, on which
> the sbrk() implementation relied. This is no longer true. Mappings can
> be created anywhere in the map, and it turns out that some are created
> immediately following the heap, preventing sbrk() from doing its job.

OK! Then maybe the sbrk() feature should be flagged as not available in order
not to fool configure and the compiler. In fact FreeBSD/arm64 did exactly that,
see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24892 So that platform is on
the same par as GNU/Hurd then. On all other supported platforms emacs builds and
runs perfectly, though.

> Now, we could fix this by doing the same thing Linux does, but as usual,
> someone has to do it, and the benefits aren't that big. Our virtual
> spaces have never been as tidy as on other systems, and it doesn't
> prevent most programs from working just fine. It usually matters for
> things like emulators, such as Wine,

Wine already builds and works on Hurd when I last tested it. Do you mean it does
not work any longer, it's been some time since I tried it?

> or debuggers like Valgrind,

There are efforts to port Valgrind to Hurd too, It's even in the TODO project
list. What to do, remove that task from the list?

> which
> have strong requirements regarding address values, but we currently
> don't build them because other dependencies are missing.

See above.

> In other words, we can't go back for now, especially not just to make
> an obsolete interface used by only one piece of software that is
> likely to fix the issue soon. Unless you really want to work on those
> red-black trees, stop pinging about this issue.

The current discussion on emacs-devel reveals that unexec will not be replaced
in the near future. The main discussion is about if the dumper should be written
in C or elisp. Until then, unexec will probably not be removed from emacs
upstream. Maybe not until the needed features are removed from glibc. (similar
situation as mlockall/munlockall on Hurd)

And: Consider vi* not building for more than a year, due to the same reason,
what would you have done then? Not everybody use vi* as their editor.