使用yocto配方构建go项目时，ABI不匹配

Question

I'm trying to write a Yocto recipe to build a Go lang project for the x86_64 target platform (rocko branch). My yocto recipe builds the Go project fine, resolving dependencies with dep tool. But the binary built doesn't run on the target platform. When trying to execute it on the target, I get this error:

$ /usr/bin/mybin
abi mismatch detected between the executable and libstd.so
fatal error: abi mismatch
runtime: panic before malloc heap initialized

This is my custom recipe to build the project:

GO_IMPORT = "bitbucket.org/xxx/myproject"
SRC_URI = "git://${GO_IMPORT}/protocol=http;user=${GIT_USER}:${GIT_PASS};destsuffix=${PN}-${PV}/src/${GO_IMPORT}"
SRCREV = "7777ee7777777c9777774bb777780777759d777771777"

CGO_ENABLED = "0"

inherit go

do_compile_prepend() {
    rm -f ${WORKDIR}/build/src/${GO_IMPORT}/Gopkg.toml
    rm -f ${WORKDIR}/build/src/${GO_IMPORT}/Gopkg.lock
    cd ${WORKDIR}/build/src/${GO_IMPORT}
    dep init
    dep ensure
}

do_install_append() {
    rm -f ${D}/usr/bin/dep
}

deltask do_compile_ptest_base
deltask do_compile_ptest

DEPENDS = "go-dep-native mercurial-native"

INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
INHIBIT_PACKAGE_STRIP = "1"

RDEPENDS_${PN}-staticdev += "bash"
RDEPENDS_${PN}-dev += "bash"

What should be the proper way to manage this issue?

Answer 1

Ok, so I found the a better way of prevent this problem and also more information about the core problem.

Better Solution

In your recipe add the following line:

GO_LINKSHARED = ""

This will prevent -builmdmode=shared and do a normal go build instead of linking against a standard library. Funny thing, by removing the linking to the standard library I only added 100KB to my bianry size and libstd.so is 30MB.

Core Problem

The core problem is that when you are using the default shared buildmode, when you build a go binary you also build the go runtime libstd.do in another rpm package. In theory, if your target has the same runtime library version then you do not need to install the runtime again. This however does not appear to be the case. Go hashes all the package definitions it puts into libstd and then hashes those hashes in order to create the ABI hash. Two instances of libstd.so of the same go version should have the same hash, because the have the same functions, but that does not appear to be the case. I wrote a more technical bug report on yocto's bug tracker here.