From: Joel Brobecker <brobecker@adacore.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org
Subject: Re: GDB 9.1 release 2019-12-23 update
Date: Tue, 24 Dec 2019 03:47:00 -0000 [thread overview]
Message-ID: <20191224034652.GA25918@adacore.com> (raw)
In-Reply-To: <835zi7xh7o.fsf@gnu.org>
> > So, as far as I know, the only issues that are still open are
> > the issues that Eli found with the pre-release.
>
> Sorry about that.
Not your fault!
> > - [EliZ] readline/colors.c build failure
> >
> > Caused by S_IXGRP and S_IXOTH not being defined on MinGW.
> > Patch sent to readline, and should be applied to our local
> > tree soon.
>
> Will do soon.
Nice.
> > - [EliZ] configure warning when checking for pthread-config
> >
> > Problem understood, but EliZ blocked because he doesn't have
> > the correct auto-tools version. Hopefully building those
> > from source is an option.
>
> I believe this was already fixed.
Double Nice.
> > - [Eliz] libtcf fails to build on MinGW
> > https://sourceware.org/bugzilla/show_bug.cgi?id=25155
> >
> > Problem reported to binutils on Dec 17th, but so far
> > no answer as far as I can tell.
> > https://sourceware.org/ml/binutils/2019-12/msg00277.html
> >
> > If we don't get an answer after the end of year holidays,
> > I suggest we send in a patch, which will likely help move
> > things along. From Eli's message on bugzilla, we shouldn't
> > be far from having one.
>
> I already have a patch, so I can apply it whenever you say so.
Let's try to have it reviewed by the binutils folks if we can.
It seems relatively straightforward, but I tend to avoid fixing
things in a branch before it gets fixed in master. Maybe send
the patch to binutils with an RFA? If that doesn't work, then
we'll consider the option of just patching our branch so
we can release.
> > Are there other issues that I may have missed for which we should
> > wait until we can release GDB 9.1?
>
> What about the compilation warning in record-btrace.c I reported in
> https://sourceware.org/ml/gdb-patches/2019-12/msg00706.html? Do we
> want to fix it?
We can, but (IMO) not super critical. FWIW, I don't get the warning
when buidling on GNU/Linux.
--
Joel
next prev parent reply other threads:[~2019-12-24 3:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-23 9:30 Joel Brobecker
2019-12-23 14:14 ` Eli Zaretskii
2019-12-23 14:32 ` Eli Zaretskii
2019-12-24 3:47 ` Joel Brobecker [this message]
2019-12-24 12:24 ` Andrew Burgess
2019-12-24 15:52 ` Eli Zaretskii
2020-01-03 16:21 ` Tom Tromey
2019-12-24 16:21 ` Eli Zaretskii
2019-12-26 22:40 ` Christian Biesinger via gdb-patches
2019-12-27 7:49 ` Eli Zaretskii
2019-12-25 21:36 ` Andrew Burgess
2020-01-02 10:56 ` Joel Brobecker
2020-01-06 22:00 ` Andrew Burgess
2019-12-28 16:22 ` Hannes Domani via gdb-patches
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191224034652.GA25918@adacore.com \
--to=brobecker@adacore.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox