[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Samuel Thibault
Subject: Re: Heads up: Recent status: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Sat, 10 Dec 2016 21:34:27 +0100
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)


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

> 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

weak_alias (__brk, brk)


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]