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

[Samuel Thibault]

Hello,

Svante Signell, on Sat 10 Dec 2016 20:52:20 +0100, wrote:
> On Thu, 2016-12-08 at 16:32 +0100, Richard Braun wrote:
> > On Thu, Dec 08, 2016 at 03:40:34PM +0100, Svante Signell wrote:
> > 
> > > 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.
> 
> Samuel. It seems like sbrk() is still needed for elf/dl-sysdep.c, and
> cannot be removed easily. Why, when malloc() is the preferred usage?

See the comment. The allocation there *has* to be exactly at that
address.

> Otherwise sbrk for Hurd should be removed completely, since it does not
> work as expected.

No need to remove it completely: you could just remove the sbrk/brk
aliases:

weak_alias (__brk, brk)

and

weak_alias (__sbrk, sbrk)

dl-sysdep.c will still be able to use __sbrk.

I'm however concerned with breaking all applications which make use of
brk/sbrk that way.  Couldn't emacs be made to know that it shouldn't use
sbrk on GNU/Hurd?

> I saw your patch wrt PIE builds, that feels like a brown paper bag
> fix!

Which patch?  What is the relation with the problem at stake?

> > Then find out how they do it, and see if we can do the same.
> 
> Richard: Any ideas on where to start? I patched brk/sbrk to return
> proper error codes, but to no avail.

emacs' configure probably doesn't check for the actual value being
returned. Just try to remove the aliases. But really I don't think we
want to do that, but rather hardcode in emacs that sbrk shouldn't be
used on GNU/Hurd.

> And, BTW, linux and kfreebsd use
> the implementations in misc, but not Hurd, why?

See the code, it's just a wrapper around __brk.

Samuel