Making juju work better with gccgo

[David Cheney]

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.penhey at 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 at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev