On Tue, Jan 17, 2017 at 8:44 AM, Lynn A. Boger <labo...@linux.vnet.ibm.com> wrote: > In the past, the libgo version number has always matched the Go version, not > the gcc release. > > The libgo for Go 1.7 and Go 1.8 are not the same. If someone wanted to > build gccgo for Go 1.7 using an old commit > > maybe for testing or comparison purposes, the libgo version would not > identify which one it was because > > libgo.so.10 could be either Go 1.7 or 1.8. Maybe nobody cares about doing > that. It's not a huge deal to me but > > it would be a point of confusion. > > GCC 6.x was Go 1.6.
I do usually update the version number for each major import (and I do usually forget to do it the first time around). I committed this patch to mainline. Ian
Index: gcc/go/gofrontend/MERGE =================================================================== --- gcc/go/gofrontend/MERGE (revision 244733) +++ gcc/go/gofrontend/MERGE (working copy) @@ -1,4 +1,4 @@ -b573d4756096523d8bd4bf7b11e56383e5a2cca4 +6d8ef03e760ff737ff2c613642142290b0f02e0e The first line of this file holds the git revision number of the last merge done from the gofrontend repository. Index: libgo/configure.ac =================================================================== --- libgo/configure.ac (revision 244166) +++ libgo/configure.ac (working copy) @@ -11,7 +11,7 @@ AC_INIT(package-unused, version-unused,, AC_CONFIG_SRCDIR(Makefile.am) AC_CONFIG_HEADER(config.h) -libtool_VERSION=10:0:0 +libtool_VERSION=11:0:0 AC_SUBST(libtool_VERSION) AM_ENABLE_MULTILIB(, ..)
