Custom Build: issue with balena engine build

Hello everyone, I’m trying to create a Custom build for a xilinx FPGA board and I face an issue when trying to compile the balena engine using the corresponding yocto warrior meta layers. I’m following the Supporting-your-Own-Board guide.

The corresponding meta-balena/meta-balena-common/recipes-containers/balena/balena_git.bb -> do_compile reports an error:
| Package devmapper was not found in the pkg-config search path.
| Perhaps you should add the directory containing `devmapper.pc’
| to the PKG_CONFIG_PATH environment variable
| No package ‘devmapper’ found
| Removing bundles/
|
| —> Making bundle: dynbinary-balena (in bundles/dynbinary-balena)
| Building: bundles/dynbinary-balena/balena-engine-18.09.10-dev
| # errors
| compile: version “go1.10.8” does not match go tool version “go1.12.9”
| # math/bits
| compile: version “go1.10.8” does not match go tool version “go1.12.9”

Do you have any ideas what might cause this? My guess is that I missed something that tells the layer to use a specific golang version toolset and instead it uses the poky one (poky-ref=a19e3961a4 => go 1.12)

The development environment can be found here https://github.com/nikooiko/balena-xilinx/blob/master/builder/Dockerfile (I’m using a docker container as a builder but I also have the same dependencies installed for native yocto build).

hey @nikooiko,

I’ve been doing some work on our go integration related to the balena-engine update recently

I had numerous problems with the (go) version selection on the yocto side of things. Your error seems to be related to having multiple go toolchains installed in parallel, see here for a little more details on that

Hello @robertgzr thanks for your feedback. I’ll look into this to see if I can find what is causing this issue.

If I understand correctly, the ‘balena’ recipe specifies a specific GOPATH at its ‘do_compile’ compile task that should override the default GOPATH that is specified by POKY.

I’m not that experienced with yocto workflow but I’m trying to debug the issue using logs and here is some additional information:

balena > balena_git.bb:

do_compile() {
  ...
  export GOPATH="${S}/src/import/.gopath:${S}/src/import/vendor:${STAGING_DIR_TARGET}/${prefix}/local/go"
  bbwarn "GOPATH='${GOPATH}', value-should-be='${S}/src/import/.gopath:${S}/src/import/vendor:${STAGING_DIR_TARGET}/${prefix}/local/go'"
  ...
}

and the result output is this:

WARNING: balena-18.09.10-dev+git7cb464a406748016f2df0c31a9851d20456a3d31-r0 do_compile: GOPATH='/workdir/build/tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/balena/18.09.10-dev+git7cb464a406748016f2df0c31a9851d20456a3d31-r0/build', value-should-equal='/workdir/build/tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/balena/18.09.10-dev+git7cb464a406748016f2df0c31a9851d20456a3d31-r0/git/src/import/.gopath:/workdir/build/tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/balena/18.09.10-dev+git7cb464a406748016f2df0c31a9851d20456a3d31-r0/git/src/import/vendor:/workdir/build/tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/balena/18.09.10-dev+git7cb464a406748016f2df0c31a9851d20456a3d31-r0/recipe-sysroot//usr/local/go

I would expect that GOPATH would equal value-should-equal but that is not the case. Anyhow, I’m guessing that the value of value-should-equal is the expected one.

We do the go version selection via this env var in meta-balena: https://github.com/balena-os/meta-balena/blob/c6a9c9490c1ef8ef854b4afc96d4fcfae0c9928b/meta-balena-common/conf/distro/include/balena-os.inc#L94

but that’s strange. I have not seen this particular issue before… since you’re logging right after we’re setting the the GOPATH var I wouldn’t expect those values to differ

I was just looking at this. If I manually set GOVERSION = “1.10.8” at the warior -> layer.conf the recipe can be compiled without problems. So now I must find out why this file is not included. I guess that I missed a setting somewhere and that causes the malfunction.

Regarding the log and the result value right below its assignment, that also seemed weird to me but I was not able to understand why this happens. Even at a successful build, the same thing happens, the log reports a different GOPATH than the expected value.

Hmm, I guess this is it.

samples/local.conf.sample

# Resin specific distros
DISTRO ?= "resin-systemd"

I’ll start the build now to see if everything is ok.

Thanks for you feedback.