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 go v1.2. (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? r~ -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
