Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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


  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