[OE-core] Go runtime host contamination

[Paul Barker]

Hey,

I'm trying to upgrade runc-opencontainers in meta-virtualization to
v1.0.0-rc4 and hitting a host contamination issue.

Both host and target are x86-64 but I'm using glibc on the host
(Ubuntu 16.04) and musl on the target. I'm getting link failures
referring to missing symbols "__vfprintf_chk" and "__fprintf_chk" in
libcontainer. I'm pretty sure these symbols exist in glibc but not in
musl.

The failure is occurring when trying to link libcontainer which uses
the go extension cgo to incorporate some c code in with the go code.

Using a pretty dumb grep, I can see the contamination in the go-runtime package:

    $ grep -r __fprintf_chk
tmp/work/core2-64-oe-linux-musl/go-runtime/1.9-r0/image/
    Binary file
tmp/work/core2-64-oe-linux-musl/go-runtime/1.9-r0/image/usr/lib/go/src/host-tools/trace
matches
    Binary file
tmp/work/core2-64-oe-linux-musl/go-runtime/1.9-r0/image/usr/lib/go/src/host-tools/pprof
matches
    Binary file
tmp/work/core2-64-oe-linux-musl/go-runtime/1.9-r0/image/usr/lib/go/pkg/linux_amd64/runtime/cgo.a
matches

The go build process seems to build host tools & runtime first and
then the target runtime, even for the go-runtime recipe. It looks like
it's installing the host version of the runtime library instead of the
target version but I'm not 100% sure here. There is some code in
go/src/make.bash to handle the case when host arch & os match target
arch & os and I think this is getting tripped up.

I can provide further info and logs tomorrow. Just wondering if anyone
has seen this sort of problem before and has any suggestions.

Cheers,

-- 
Paul Barker
Togán Labs Ltd