This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: binutils version of snapshot builds
On Wed, 21 Mar 2007, Matthias Klose wrote:
> That doesn't change the snapshot builds, I still get "070315.20070315".
Then I think there's some bug in the snapshot generation process,
"2.17.50.20070315" would be appropriate not "070315.20070315".
> Configuring a snapshot build --with-pkgversion="Ubuntu 2.17.20070321cvs-1" (the
> latter beeing the package version) I end up with a version string:
>
> "GNU ld (Ubuntu 2.17.20070321cvs-1) 2.17.50.20070321"
>
> That doesn't look robust with the current practice of scanning the ld version.
It conforms to the GNU Coding Standards definition of version numbers.
GCC's ld version number checks have been fixed (libstdc++ had hardcoded
checks for the word "version" that used to be there).
> Would it be more appropriate to append the package version information like it
> is done in gcc? For now I avoid adding the package version into the PKGVERSION
> string.
The current GCC practice, "4.3.0 20070319 (experimental)" at the end, does
not conform to the GNU Coding Standards.
Appending to the end of the string, as well as not conforming to the GNU
Coding Standards, breaks other version checks. The checks in glibc for as
and ld versions, for example, extract the last version number found.
Note that if PKGVERSION includes a version number that number may relate
to a larger package and have nothing to do with GNU binutils version
numbers, so appending to the end is liable to break the glibc version
checks.
> Unrelated to your patch: Building the snapshot using an earlier snapshot having
> the same sonames for the shared libraries fails with an as segfault for the
> first file in opcodes. This could be avoided including the date string in the
> soversion (bfd/configure.in). Are there reasons against this configuration
> (besides ending up with a version string "2.17.50.20070321.20070321")?
I think having 2.17.50.20070321 in the SONAME is reasonable.
--
Joseph S. Myers
joseph@codesourcery.com