This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: binutils version of snapshot builds
Joseph S. Myers schrieb:
> On Tue, 20 Mar 2007, Matthias Klose wrote:
>
>> The version for ld/as, when built from the snapshot tarballs is just the release
>> date ("070315"); using the snapshots to build software checking for a particular
>> binutils version usually breaks; all configure tests I've seen check for
>> X.Y[.Z]. A version like 2.17.50.070315 would make more sense (but currently does
>> not correlate with the version from a build from cvs ("2.17.50"). How could this
>> version information be unified?
>
> I don't know about snapshots, but the --version output from CVS binutils
> should now be like
>
> GNU assembler (GNU Binutils) 2.17.50.20070320
>
> ever since my patch
>
> 2007-03-01 Joseph Myers <joseph@codesourcery.com>
>
> * Makefile.am (bfdver.h): Use "." not " " between version number
> and date.
> * Makefile.in: Regenerate.
> * configure.in (PKGVERSION): Default to "(GNU Binutils) ".
> * configure: Regenerate.
That doesn't change the snapshot builds, I still get "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.
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.
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")?
Matthias