[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <10f4fb0b-1012-b0e6-af05-0aa5a906de21@redhat.com>
Date: Thu, 14 May 2020 12:34:53 +0100
From: Nick Clifton <nickc@...hat.com>
To: Nick Desaulniers <ndesaulniers@...gle.com>,
Fangrui Song <maskray@...gle.com>,
"H.J. Lu" <hjl.tools@...il.com>
Cc: Masahiro Yamada <masahiroy@...nel.org>,
Sedat Dilek <sedat.dilek@...il.com>,
Nick Desaulniers <nick.desaulniers@...il.com>,
Michal Marek <michal.lkml@...kovi.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Changbin Du <changbin.du@...el.com>,
Randy Dunlap <rdunlap@...radead.org>,
Krzysztof Kozlowski <krzk@...nel.org>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Clang-Built-Linux ML <clang-built-linux@...glegroups.com>
Subject: Re: [PATCH] Makefile: support compressed debug info
Hi Nick,
> + Nick, H.J.
> I'm unfamiliar with the git tag conventions of binutils. Does a patch
> that landed in 2.25.51.0.4 mean it shipped in the official 2.25
> release, or 2.26 release? Specifically, commit 19a7fe52ae3d.
2.26.
The convention is that a released form of the binutils has a version
number of X.XX or possible X.XX.N. The current mainline development
sources have a version of X.XX.50 where X.XX is the latest release.
(So the current mainline sources are version 2.34.50). When a release
happens the XX value is incremented by one as part of the release
process, and the .50 is dropped. (So the next binutils release will
be 2.35).
So 2.25.51.0.4 is a development version which will then have been
released as binutils 2.26.
Cheers
Nick
Powered by blists - more mailing lists