Thanks Tim, I think we're in the position that even if you don't use gccgo for your own development (understandable, it is slower), now that we have platforms we support in Trusty that must use gccgo, armv8 and ppc64el, for any new development, the code has to pass under both compilers.
This is a bit of a bummer, but at least if you are running trusty on your development environment, you have all the bits you need[1][2]. Running tests, for a single package then becomes go test && go test -compiler=gccgo With respect to the whole Juju test suite, even after months of work there still remain a few tests which do not pass under trusty, these are tracked with bugs in lp, just look for the gccgo label if you find yourself at a loose end. Cheers Dave [1] Prior to trusty, you'd probably be using gccgo-4.8, which is not of acceptable quality for use with Juju. [2] If for some reason you don't want to upgrade to trusty, we may be able to ask Doko for a backport of gccgo-4.9, but really, just upgrade to trusty. On Fri, May 16, 2014 at 12:44 PM, Tim Penhey <tim.pen...@canonical.com> wrote: > I realise I left this bit hanging: > > On 16/05/14 14:41, Tim Penhey wrote: >> A key issue that Dave and I have been poking with a stick is the test >> suite for juju/errgo, as it had some failures with gccgo (all passed >> with gc). > > In the end it had to do with the runtime.Caller method for stack > analysis, and the synthetic methods that gccgo was creating. The > solution was simply enough to convert the tests to use gocheck, that way > the synthetic methods that were being created are higher in the stack > that we ever look in the tests, and it is all good. > > Tim > > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev