juju must install the libgo.so.5 library when required

[Dave Cheney]

Unlike golang-go compiled tools, gccgo compiled tools are not self contained.

$ /var/lib/juju/tools/machine-1/jujud
/var/lib/juju/tools/machine-1/jujud: error while loading shared libraries: libgo.so.5: cannot open shared object file: No such file or directory

ubuntu@ubuntu-local-machine-1:~$ ldd /var/lib/juju/tools/machine-1/jujud
        linux-vdso64.so.1 => (0x00003fff86b70000)
        libgo.so.5 => not found
        libgcc_s.so.1 => /lib/powerpc64le-linux-gnu/libgcc_s.so.1 (0x00003fff86b48000)
        libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x00003fff86988000)
        /lib64/ld64.so.2 (0x000000005b6b5000)

For environments where gccgo compiled tools are going to be deployed we need to ensure that _all_ machines in the environment have this library installed by cloud init.

This needs to happen before we try to setup the upstart jobs, because the daemons will not be able to start.

[James Page (james-page)]

how about statically linking it - that's what the packaging in trusty currently does for ppc64el and arm64

[Dave Cheney (dave-cheney)]

I can try, that will be burried somewhere in the Go tool

On Fri, Mar 14, 2014 at 7:05 PM, James Page <email address hidden> wrote:
> how about statically linking it - that's what the packaging in trusty
> currently does for ppc64el and arm64
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1292353
>
> Title:
> juju must install the libgo.so.5 library when required
>
> Status in juju-core:
> Triaged
>
> Bug description:
> Unlike golang-go compiled tools, gccgo compiled tools are not self
> contained.
>
> $ /var/lib/juju/tools/machine-1/jujud
> /var/lib/juju/tools/machine-1/jujud: error while loading shared libraries: libgo.so.5: cannot open shared object file: No such file or directory
>
> ubuntu@ubuntu-local-machine-1:~$ ldd /var/lib/juju/tools/machine-1/jujud
> linux-vdso64.so.1 => (0x00003fff86b70000)
> libgo.so.5 => not found
> libgcc_s.so.1 => /lib/powerpc64le-linux-gnu/libgcc_s.so.1 (0x00003fff86b48000)
> libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x00003fff86988000)
> /lib64/ld64.so.2 (0x000000005b6b5000)
>
> For environments where gccgo compiled tools are going to be deployed
> we need to ensure that _all_ machines in the environment have this
> library installed by cloud init.
>
> This needs to happen before we try to setup the upstart jobs, because
> the daemons will not be able to start.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1292353/+subscriptions

[James Page (james-page)]

See http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/juju-core/trusty/view/head:/debian/rules#L33

[John A Meinel (jameinel)]

So I'm pretty sure we want: JUJUD_FLAGS:= -gccgoflags -static-libgo
Is this that "juju bootstrap --upload-tools" also needs to know that it needs to pass -static-libgo" when building the binary?
Do we want to add something like this to a "make install" target so that when people are developing with gccgo it does the right thing by default?

[John A Meinel (jameinel)]

I'm not sure that this is a Critical for 1.18/1.17.6 bug, given the packaging seems to do the right thing, and we have a workaround (tell people to supply the -static-libgo flag when building/installing locally).

[Dave Cheney (dave-cheney)]

On Mon, Mar 17, 2014 at 4:00 PM, John A Meinel <email address hidden>wrote:

> So I'm pretty sure we want: JUJUD_FLAGS:= -gccgoflags -static-libgo
> Is this that "juju bootstrap --upload-tools" also needs to know that it
> needs to pass -static-libgo" when building the binary?
>

In almost all cases juju bootstrap --upload-tools, for developers, will use
$GOPATH/bin/juju{,d}, so you have to make sure you *ALWAYS* link statically
because you can't assert that bootstrap won't grab itself and upload it as
the tools

End users using released tools will most likely be unaffected by this as
their tools are built statically -- james page showed me the spot in
debian/rules.

> Do we want to add something like this to a "make install" target so that
> when people are developing with gccgo it does the right thing by default?
>
>
> ** Changed in: juju-core
> Milestone: 1.18.0 => 1.17.6
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1292353
>
> Title:
> juju must install the libgo.so.5 library when required
>
> Status in juju-core:
> Triaged
>
> Bug description:
> Unlike golang-go compiled tools, gccgo compiled tools are not self
> contained.
>
> $ /var/lib/juju/tools/machine-1/jujud
> /var/lib/juju/tools/machine-1/jujud: error while loading shared
> libraries: libgo.so.5: cannot open shared object file: No such file or
> directory
>
> ubuntu@ubuntu-local-machine-1:~$ ldd /var/lib/juju/tools/machine-1/jujud
> linux-vdso64.so.1 => (0x00003fff86b70000)
> libgo.so.5 => not found
> libgcc_s.so.1 => /lib/powerpc64le-linux-gnu/libgcc_s.so.1
> (0x00003fff86b48000)
> libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6
> (0x00003fff86988000)
> /lib64/ld64.so.2 (0x000000005b6b5000)
>
> For environments where gccgo compiled tools are going to be deployed
> we need to ensure that _all_ machines in the environment have this
> library installed by cloud init.
>
> This needs to happen before we try to setup the upstart jobs, because
> the daemons will not be able to start.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1292353/+subscriptions
>

[Dave Cheney (dave-cheney)]

I've been asked to make ppc64el bugs as high/critical for the next release,
was 1.18.0, now 1.17.6

On Mon, Mar 17, 2014 at 4:00 PM, John A Meinel <email address hidden>wrote:

> I'm not sure that this is a Critical for 1.18/1.17.6 bug, given the
> packaging seems to do the right thing, and we have a workaround (tell
> people to supply the -static-libgo flag when building/installing
> locally).
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1292353
>
> Title:
> juju must install the libgo.so.5 library when required
>
> Status in juju-core:
> Triaged
>
> Bug description:
> Unlike golang-go compiled tools, gccgo compiled tools are not self
> contained.
>
> $ /var/lib/juju/tools/machine-1/jujud
> /var/lib/juju/tools/machine-1/jujud: error while loading shared
> libraries: libgo.so.5: cannot open shared object file: No such file or
> directory
>
> ubuntu@ubuntu-local-machine-1:~$ ldd /var/lib/juju/tools/machine-1/jujud
> linux-vdso64.so.1 => (0x00003fff86b70000)
> libgo.so.5 => not found
> libgcc_s.so.1 => /lib/powerpc64le-linux-gnu/libgcc_s.so.1
> (0x00003fff86b48000)
> libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6
> (0x00003fff86988000)
> /lib64/ld64.so.2 (0x000000005b6b5000)
>
> For environments where gccgo compiled tools are going to be deployed
> we need to ensure that _all_ machines in the environment have this
> library installed by cloud init.
>
> This needs to happen before we try to setup the upstart jobs, because
> the daemons will not be able to start.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1292353/+subscriptions
>

[Tim Penhey (thumper)]

Marking as fix committed for trunk developers.

We should also make sure the build commands for the package are updated.

[James Page (james-page)]

Packaging already does this.