I'm working on enabling Go on systems without golang support, but for which the
gccgo compiler works.
But in order for this to work, there needs to be some amount of coordination
with the regular golang package, the spec files of binaries written in go, and
the golang-*-devel packages.
(0) I start with a "go" driver program that is built with, and defaults to
building with, the gccgo compiler. I.e. -compiler gccgo is the default. I've
called this package "go-gccgo", for lack of a better name.
(1) I was disappointed to discover that all of the -devel packages depend on
golang. That meant that when I wanted to uninstall golang on my test system
and install my go-gccgo package, all of the development libraries were
uninstalled too. This seems silly, because the -devel packages don't *really*
depend on golang, any more than glib2-devel depends on having gcc installed.
I think that removing this unnecessary dependency can happen independent of any
other change we can make.
(2) We need some rpm token to coordinate the version of the Go language that
the installed compiler. Currently the packages check "golang >= version", but...
(3) The golang and go-gccgo packages probably ought to conflict, since both
contain a /usr/bin/go. I don't see using alternates as terribly useful here,
and anyway there may well be a Go language version conflict from (2) between
the two compilers. Certainly for f21, golang is v1.3.1, but gcc 4.9 supports
(4) For packages that build binaries written in go, like docker, we need an rpm
macro to say whether we expect to build with gccgo or gc. The command line
options for the two compilers are not compatible, and so the %build section of
the spec file needs to be adjusted (sometimes trivially, sometimes not).
I'm currently defining %use_gccgo in the /usr/lib/rpm/macros.d/macros.golang
file installed with my go-gccgo package.
(5) There's currently a %go_arches macro that specifies those arches to which
golang is ported. If go-gccgo exists, is this macro actually useful anymore?