gcc <--> binutils versions

gcc <--> binutils versions

[German Salazar]

Over time and because of different user requirements, I have ended up with
3 versions of gcc installed and, apparently, I use each with a specific
version of binutils.

Memories are vague, I either found a table indicating which version
of binutils is needed by a given version of gcc or I found out the hard way
while attempting to use gcc.

Presently, I use
binutils 2.24 with gcc 4.9.2
binutils 2.25 with gcc 5.3.0
binutils 2.26 with gcc 6.3.0

I am about to install gcc 10.3.0
*Question: which version of binutils should I use?*
I can't seem to find a hint about that, anywhere.

Thanks,
Germán

Re: gcc <--> binutils versions

[Jonathan Wakely]

On Fri, 25 Jun 2021 at 14:32, German Salazar wrote:
>
> Over time and because of different user requirements, I have ended up with
> 3 versions of gcc installed and, apparently, I use each with a specific
> version of binutils.
>
> Memories are vague, I either found a table indicating which version
> of binutils is needed by a given version of gcc or I found out the hard way
> while attempting to use gcc.
>
> Presently, I use
> binutils 2.24 with gcc 4.9.2
> binutils 2.25 with gcc 5.3.0
> binutils 2.26 with gcc 6.3.0
>
> I am about to install gcc 10.3.0
> *Question: which version of binutils should I use?*
> I can't seem to find a hint about that, anywhere.

It doesn't matter, anything made in the last ten years will work fine.
Generally, the newer the better, because GCC can take advantage of the
newer features. But it will still work without them.

Re: gcc <--> binutils versions

[Jim Wilson]

On Fri, Jun 25, 2021 at 7:59 AM Jonathan Wakely via Gcc-help <
gcc-help@gcc.gnu.org> wrote:

> On Fri, 25 Jun 2021 at 14:32, German Salazar wrote:
>
> > I am about to install gcc 10.3.0
> > *Question: which version of binutils should I use?*
> > I can't seem to find a hint about that, anywhere.
>
> It doesn't matter, anything made in the last ten years will work fine.
> Generally, the newer the better, because GCC can take advantage of the
> newer features. But it will still work without them.
>

For a stable well supported target like x86 this may be true, but for a lot
of embedded targets this won't work.

My advice would be to use the binutils version that was released right
before the gcc version was released.  Gcc-10.1 was released May 7, 2020.
So you should try using the binutils-2.34 release which was released Feb 1,
2020.

Jim

Re: gcc <--> binutils versions

[Segher Boessenkool]

On Fri, Jun 25, 2021 at 02:31:44PM -0700, Jim Wilson wrote:
> On Fri, Jun 25, 2021 at 7:59 AM Jonathan Wakely via Gcc-help <
> gcc-help@gcc.gnu.org> wrote:
> > On Fri, 25 Jun 2021 at 14:32, German Salazar wrote:
> > > I am about to install gcc 10.3.0
> > > *Question: which version of binutils should I use?*
> > > I can't seem to find a hint about that, anywhere.
> >
> > It doesn't matter, anything made in the last ten years will work fine.
> > Generally, the newer the better, because GCC can take advantage of the
> > newer features. But it will still work without them.
> 
> For a stable well supported target like x86 this may be true, but for a lot
> of embedded targets this won't work.
> 
> My advice would be to use the binutils version that was released right
> before the gcc version was released.  Gcc-10.1 was released May 7, 2020.
> So you should try using the binutils-2.34 release which was released Feb 1,
> 2020.

That version will give you the best chance that everything works, yes.
But since 10.3 was released less than three months ago, current binutils
trunk should work fine as well.  In general using the most recent of
everything will work.  There is no strict ordering requirement :-)

But, as you say, if you are building an elderly compiler, it tends to
work better to not use a binutils that is (much) newer.

For native compilers (as opposed to cross-compilers), you can expect
using the binutils that comes with some major OS to work as well --
simply because that will have been tested!  Using a random older
binutils has a lower chance of working correctly, and what is the point
anyway?


Segher

Re: gcc <--> binutils versions

[NightStrike]

On Fri, Jun 25, 2021 at 10:59 AM Jonathan Wakely via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
> On Fri, 25 Jun 2021 at 14:32, German Salazar wrote:
> >
> > Over time and because of different user requirements, I have ended up with
> > 3 versions of gcc installed and, apparently, I use each with a specific
> > version of binutils.
> >
> > Memories are vague, I either found a table indicating which version
> > of binutils is needed by a given version of gcc or I found out the hard way
> > while attempting to use gcc.
> >
> > Presently, I use
> > binutils 2.24 with gcc 4.9.2
> > binutils 2.25 with gcc 5.3.0
> > binutils 2.26 with gcc 6.3.0
> >
> > I am about to install gcc 10.3.0
> > *Question: which version of binutils should I use?*
> > I can't seem to find a hint about that, anywhere.
>
> It doesn't matter, anything made in the last ten years will work fine.
> Generally, the newer the better, because GCC can take advantage of the
> newer features. But it will still work without them.

I have found that older binutils don't scale well with newer gcc once
you try doing anything but the basics, even on x86_64 / Linux.  It's
largely why I kind of wish the projects were not separate.

The same goes for gdb.  You just can't use  an old gdb with a new gcc
and expect things to work without using additional options to force
legacy behavior (and even then, sometimes it won't matter).

This is why I've started making the entire toolchain,
gcc+binutils+gdb.  Although, as you've seen in certain problems you've
tried to help me with, Jon, I fail at that, too, on occasion.

Re: gcc <--> binutils versions

[German Salazar]

This is why, additionally, it is nice to know whether version numbers for
given software are meaningful, for example, are they following Semantic
Versioning? That would give clear indication of how far to update.

I see that page https://ftp.gnu.org/gnu/binutils lists releases since 1996,
starting with version 2.6 ...25 years later, they continue with major
version 2 ...that this mean that they are all backwards compatible? If that
is the case, then, I should be able to use even binutils released after the
version of gcc I am trying to use, correct?

On Sun, Jun 27, 2021 at 4:58 PM NightStrike <nightstrike@gmail.com> wrote:

> On Fri, Jun 25, 2021 at 10:59 AM Jonathan Wakely via Gcc-help
> <gcc-help@gcc.gnu.org> wrote:
> >
> > On Fri, 25 Jun 2021 at 14:32, German Salazar wrote:
> > >
> > > Over time and because of different user requirements, I have ended up
> with
> > > 3 versions of gcc installed and, apparently, I use each with a specific
> > > version of binutils.
> > >
> > > Memories are vague, I either found a table indicating which version
> > > of binutils is needed by a given version of gcc or I found out the
> hard way
> > > while attempting to use gcc.
> > >
> > > Presently, I use
> > > binutils 2.24 with gcc 4.9.2
> > > binutils 2.25 with gcc 5.3.0
> > > binutils 2.26 with gcc 6.3.0
> > >
> > > I am about to install gcc 10.3.0
> > > *Question: which version of binutils should I use?*
> > > I can't seem to find a hint about that, anywhere.
> >
> > It doesn't matter, anything made in the last ten years will work fine.
> > Generally, the newer the better, because GCC can take advantage of the
> > newer features. But it will still work without them.
>
> I have found that older binutils don't scale well with newer gcc once
> you try doing anything but the basics, even on x86_64 / Linux.  It's
> largely why I kind of wish the projects were not separate.
>
> The same goes for gdb.  You just can't use  an old gdb with a new gcc
> and expect things to work without using additional options to force
> legacy behavior (and even then, sometimes it won't matter).
>
> This is why I've started making the entire toolchain,
> gcc+binutils+gdb.  Although, as you've seen in certain problems you've
> tried to help me with, Jon, I fail at that, too, on occasion.
>

Re: gcc <--> binutils versions

[Segher Boessenkool]

On Sun, Jun 27, 2021 at 05:38:21PM -0400, German Salazar via Gcc-help wrote:
> This is why, additionally, it is nice to know whether version numbers for
> given software are meaningful, for example, are they following Semantic
> Versioning? That would give clear indication of how far to update.

"Semantic versioning" is meaningless itself: you really need to know
exactly what is meant by it.  Different people have different
expectations of it.  And it is often presented as magic pixie dust.

The version numbers *are* meaningless, and they *should* be: binutils is
just released at a regular cadence.  

> I see that page https://ftp.gnu.org/gnu/binutils lists releases since 1996,
> starting with version 2.6 ...25 years later, they continue with major
> version 2 ...that this mean that they are all backwards compatible? If that
> is the case, then, I should be able to use even binutils released after the
> version of gcc I am trying to use, correct?

Yes.  But most combinations will not have been tested, or anticipated,
so YMMV.  If you stay on the beaten track things will work more smoothly
for you.


Segher

Re: gcc <--> binutils versions

[German Salazar]

Hope I am not hijacking my own thread that much; after all, the word
"versions" is in the title.

I don't agree that version numbers should be meaningless.

Semantic Versioning is not meaningless and it is very well spelled out what
is meant by it.  Refer to https://semver.org/

For the in-house programs that I manage, I use Semantic Versioning which
provides me with real life benefits, for example, dependency compatibility
and long term support.

For example, let's say:

   - program B V4.2.1 is the latest production version at the time program
   A is written
   - program A depends on B to do some processing; to that end, A knows how
   to put together the input for B and knows how to read its output, too


What I do in the launcher for A is to specify that it requires B V4.x;
meaning, it should pick up the greatest version 4 available.  In this way,
program A benefits from any bug fixes done on B and released in, say,
V4.2.2, V4.2.3, etc. ; or even from backwards compatible enhancements in B
released in versions V4.3.x, V4.4.x, etc.

When program B V5.0.0 is released, program A knows not to use it since it
is not backwards compatible; and, so, program A does not break and
continues to work just fine.

Of course, this requires that a program release does not over-write the
previous version so that one ends up with just one version (the leates)
deployed; instead, I must keep all version out there, or at least the
latest from every major release.

Those are my 2 cents.
Germán