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

[Richard Braun]

On Thu, Dec 08, 2016 at 03:40:34PM +0100, Svante Signell wrote:
> I've read it, thanks! I think emacs is in a similar situation as Hurd with
> respect to the still missing mlockall/munlockall functions.

Except we're not fighting to keep the status quo. We will adapt and
implement these dependencies. I started working on it very recently
by the way. Give it a bit more time please.

> 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.

Then find out how they do it, and see if we can do the same.

> 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?

I mean it's really lucky that it works.

> 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?

I mentioned there are other dependencies. We can deal with them first,
and virtual allocations later.

> 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)

The current discussion here is not about unexec, but its current
dependencies. The implementation of unexec is likely to change.
We'll see then if the new upstream code is fine for the Hurd or not.

> 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.

It did happen actually, that vim suffered from a severe bug that made
it very slow [1]. What would I have done ? Well I fixed it [2], a work
of over a year because it required the Hurd code to switch from its
native cthreads to pthreads [3]. I dare you to do the same.

-- 
Richard Braun

[1] https://www.gnu.org/software/hurd/open_issues/select.html
[2] 
https://git.sceen.net/hurd/hurd.git/commit/hurd/io.defs?id=8cd75c4d6b229bb4e3de9264466731e3a32e0133
[3] 
https://git.sceen.net/hurd/hurd.git/commit/libports/count-bucket.c?id=1de0643c9218db536f5b2e294bbfa653c77438e4