Hi Simon!
On Wed, 7 Dec 2016 16:28:58 -0500, Simon Marchi
wrote:
> On 16-12-07 04:09 PM, Thomas Schwinge wrote:
> > commit 14f6890677849172a4b13779acd9089c9baa3a81
> > Author: Thomas Schwinge
> > Date: Tue May 24 19:36:57 2016 +0200
> >
> > Hurd: Adjust to "Per-inferior/Inferior-qualifie
Hello bug-hurd ML,
Since a long time emacs FTBFS due to unknown reasons. The latest version
building was Debian 24.5+1-5, from 28 Nov 2015.
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
Hi!
On Fri, 11 Sep 2015 11:38:15 -0700, Don Breazeal wrote:
> Here is what I pushed.
> --- a/gdb/remote.c
> +++ b/gdb/remote.c
> @@ -6089,11 +6178,42 @@ Packet: '%s'\n"),
> event->ws.kind = TARGET_WAITKIND_VFORK_DONE;
> p = skip_to_semicolon (p1 + 1);
> }
> +
Hi!
On Sat, 24 Sep 2016 16:13:30 -0400, Simon Marchi
wrote:
> --- a/gdb/inferior.c
> +++ b/gdb/inferior.c
> +void
> +print_selected_inferior (struct ui_out *uiout)
> +{
> + char buf[PATH_MAX + 256];
> + struct inferior *inf = current_inferior ();
> +
> + xsnprintf (buf, sizeof (buf),
> +
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.
> Even befor
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
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 dependencie
On 2016-12-08 07:01, Thomas Schwinge wrote:
On GNU/Hurd, there is no "#define PATH_MAX", so this fails to build.
(I'm aware that there is other PATH_MAX usage in GDB sources, which we
ought to fix at some point, for example in gdbserver -- which is not
yet
enabled for GNU/Hurd.)
Unless I miss
Hi!
On Thu, 08 Dec 2016 10:25:53 -0500, Simon Marchi
wrote:
> On 2016-12-08 07:01, Thomas Schwinge wrote:
> > On GNU/Hurd, there is no "#define PATH_MAX", so this fails to build.
> > --- gdb/inferior.c
> > +++ gdb/inferior.c
> > [...]
> Yeah it looks much better. Also, if you want to factor o
Hi!
On Thu, 2 Oct 2014 17:21:34 +0100, Pedro Alves wrote:
> When GDB wants to sync the thread list with the target's [...]
> --- a/gdb/thread.c
> +++ b/gdb/thread.c
> void
> update_thread_list (void)
> {
> - prune_threads ();
> - target_find_new_threads ();
> + target_update_thread_list
10 matches
Mail list logo
