From: Joel Sherrill <joel.sherrill@oarcorp.com>
To: Nicholas Clifton <nickc@redhat.com>,
Tristan Gingold <gingold@adacore.com>,
Joel Brobecker <brobecker@adacore.com>
Cc: "binutils@sourceware.org" <binutils@sourceware.org>,
"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: Synchronizing Binutils and GDB releases
Date: Mon, 18 Aug 2014 15:42:00 -0000 [thread overview]
Message-ID: <53F21EDB.9030907@oarcorp.com> (raw)
In-Reply-To: <53F21C4B.4000109@redhat.com>
On 8/18/2014 10:31 AM, Nicholas Clifton wrote:
> Hi Tristan, Hi Joel,
>
> What do you think to the idea of synchronizing GDB and BINUTILS
> releases ?
>
> The idea was raised at this year's GNU Tool's Cauldron. It would
> help users who manage combined toolchain sources. Currently if they
> want to create a combined tree of specific releases of the gcc, gdb and
> binutils they have to choose which version of the BFD library to use.
> But if they find a bug and want to check in a fix, they have to remember
> that there are actually two versions of the BFD sources to patch.
> Multiply this by a number of different GDB/BINUTILS release
> combintations and this becomes a maintenance headache.
>
>
> If we had a combined release there would be only one branch in the
> git repository and things would be a lot simpler. We could even extend
> this idea by arranging for the release to happen slightly before each
> GCC release. Then GCC version X could could say that it works best with
> GDB/BINUTILS version Y.
I can't speak for the entire world but I know that since the move to
git, I have
been building binutils+gdb as one unit and gcc+newilb as another. It has
simplified
my testing of the RTEMS targets and appears to shave a little time off
the builds.
OTOH we have sometimes managed to upgrade a gdb on an old
binutils/gcc/newlib.
It is usually low risk because we don't try to share the BFD library. We
have treated
gdb and binutils as separate entities. Updating binutils would force us
to rebuild
gcc+newlib. If a BFD patch were needed, we would evaluate what to do. It
might be
a patch to binutils and a gdb upgrade.
But we are a unique project in that we prefer end users to build from
source. Linux
distros would be in a different position.
> Cheers
> Nick
>
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
next prev parent reply other threads:[~2014-08-18 15:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-18 15:31 Nicholas Clifton
2014-08-18 15:42 ` Joel Sherrill [this message]
2014-08-18 16:09 ` Joel Brobecker
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=53F21EDB.9030907@oarcorp.com \
--to=joel.sherrill@oarcorp.com \
--cc=binutils@sourceware.org \
--cc=brobecker@adacore.com \
--cc=gdb@sourceware.org \
--cc=gingold@adacore.com \
--cc=nickc@redhat.com \
/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