Using Juju to build gccgo

The port of Juju to Go is a project I’ve been involved in at Canonical for some time now. The power behind Juju is charms, which are part configuration management and part reliable workflow engine.

One non-conventional use of Juju is something I cooked up a while ago when traveling, a Juju charm that compiles gccgo. This charm can be used to compile gccgo on a powerful instance in your cloud rather than on your puny laptop without having to worry about finding all the various dependencies that a modern gcc build requires.

The gccgo charm encapsulates all the instructions in, all you need to do is deploy it and wait for the result.

Getting started

To get started using the gccgo charm, checkout my charms repository from GitHub.

% cd $HOME
% git clone

Bootstrap a juju environment

Each Juju service (an instance of a charm) needs to be deployed into a running environment. I’ve bootstrapped an environment on Amazon AWS as they have a nice 8 core machine which will get the job done quickly.

% juju bootstrap -e ap-southeast-2

Deploying the gccgo charm

The next step is to deploy an instance of the gccgo charm from my local charm repository. By default Juju requests the equivalent of an m1.small so we use a deploy time constraint to request a machine with a larger number of cores. The gccgo charm automatically adjusts itself to use all CPUs on the target machine.

% juju deploy --constraints "cpu-cores=8" --repository $HOME/charms \

Monitoring the status of the build

All the magic of the build phase takes place in the hooks/start hook, so the build will stay at installed until the build completes (or fails).

% juju status gccgo
environment: ap-southeast-2
    agent-state: started
    instance-id: i-22c92a1e
    instance-state: running
    series: raring
    hardware: arch=amd64 cpu-cores=8 cpu-power=2000 mem=7168M root-disk=8192M
    charm: local:raring/gccgo-12
    exposed: false
        agent-state: installed
        machine: "1"

You can also monitor the output of the build process itself using the juju debug-log command.

Grabbing the results

The gccgo charm has a number of configuration variables you can use to tweak the build process if necessary. The gccgo charm produces a tarball as its final result once the service moves to started state.

% juju get gccgo
charm: gccgo
service: gccgo
    default: true
    description: gccgo build prefix
    type: string
    value: /opt/gccgo
    default: true
    description: gccgo final tarball
    type: string
    value: /home/ubuntu/gccgo.tar.bz2
    default: true
    description: gccgo build directory
    type: string
    value: /home/ubuntu/work

Now we know the location of the tarball, we can use the juju scp command to fetch it.

juju scp gccgo/0:/home/ubuntu/gccgo.tar.bz2 /tmp

Cleaning up

8 core virtual machines don’t come cheap, don’t forget to destroy this environment (or at least destroy the service and remove the machine) once you’re done.

# destroy service and remove build machine
% juju destroy-service gccgo
% juju destroy-machine 1    # from the output of juju status above
# or destroy the environment
% juju destroy-environment -y