Strange BFD version

[th-otto]

I assume our binutils-2_41-mintelf was branched off from the binutils-2_41 tag (atleast the commit 2c73aeb is included). Nevertheless, both this branch and vincents gdb-mintelf-vri branch report version 2.40.90, which originates from

m68k-atari-mint-binutils-gdb/bfd/version.m4

Line 1 in b066005

m4_define([BFD_VERSION], [2.40.90])

Any idea why that is the case?

EDIT: btw, the commit referenced above reports 142,648 additions. WTF.

[th-otto]

I've cherry-picked now https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7872e3bdb0de234ae4ace053cde0c915ff2332d4 from the upstream master branch in my local repo, which just does the change to version 2.41, and assorted entries to ChangeLog etc. Should that be pushed or is there a more elegant way?

[vinriviere]

Indeed, I noticed there was something very strange with the binutils versioning. It seemed there was 2 tag/branches for the 2.41 release. I think I chose the right one as base, but I'm not sure. I will have a look again, I don't remember well.

Anyway, this doesn't really matter, at least for my builds. I use Git for the history of individual commits, then to produce a squashed patch. Then I apply that patch to the official source tarball when building binaries, so the version is always correct.

But it's really strange that the official sources don't precisely match official Git tag/branches. There is certainly a (bad) reason. Really weird way of using Git.

[th-otto]

There are two branches in the master repo, binutils-2_41-release-point and binutils-2_41-branch. Looks like you started from that strange binutils-2_41-release-point.

The produced code will be the same, but running m68k-atari-mintelf-as --version will report 2.40.90 as version number. That's a bit confusing, since that version has never been released. OTOH, if we add that commit, then a squashed patch probably does not apply any longer to the official 2.41 tarball.

Then I apply that patch to the official source tarball when building binaries, so the version is always

I do the same, but there is another problem with that approach, now that gdb can also be built. The official tarballs for binutils and gdb are very different, even if they originate from the same repo.

[vinriviere]

The official tarballs for binutils and gdb are very different, even if they originate from the same repo.

Yes, that's unfortunate. Generally, we port the binutils patch from the old branch to the new one, and that's done. As binutils and gdb use the same repository but 2 different branches for releases, we will have to maintain 2 branches.