On 03/13/2015 04:52 PM, Tianon Gravi wrote: > On 12 March 2015 at 09:02, Matthias Klose <[email protected]> wrote: >> gccgo, starting with GCC 5 now ships the go tool, which allows building of >> most >> packages in the archive. Instead of hard-coding any package to build-depend >> on >> gccgo on architectures where golang is unsupported, I built empty golang-go >> and >> golang-src packages which depend on gccgo instead. > > I'd be a lot more comfortable with this being a deliberate change in > the package dependencies to explicitly state that they're > gccgo-compatible, especially if failure to build or failure in the > test suite is a common occurrence.
hardcoding this into the packages will require changes then to every package having these build dependencies. well, up to now, I only have one package with a build failure in the testsuite. > Those kinds of FTBFS also only > account for compilation bugs or ones that the project test suite > happens to catch -- what worries me even more are the more subtle > runtime bugs we might introduce with such a change. so up to now, I only see exactly one (plus some where packages are not ready for Go 1.4, like golang-goyaml). If you want to investigate that one, please have a look at golang-log4go. I'd be interested if that turns out a porting issue, or a compiler issue. Up to now, all issues were found in the golang code, which is shared between golang-go and gccgo. > I'm still very much +1 to using alternatives for "go" (ala #779503), > but I'm definitely not ready to claim that GCCGO 5 and Go 1.4 are > actually equivalent and compatible to the level a virtual like this > implies. apparently they are, except for the mentioned golang-goyaml, golang-log4go, and golang-gotools, which seems to have some golang specific hacks to build the package (any help to understand why these are necessary are appreciated). Maybe an explicit gccgo-src package is needed, however all the export information should be available in the .gox files. see http://qa.ubuntuwire.com/ftbfs/ for the failing packages, feel free to comment on the issues mentioned for the packages. Matthias -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
