[OE-core] Overriding fixmepath

Kristian Amlie kristian.amlie at mender.io
Wed Jan 25 10:43:13 UTC 2017


After the new recipe sysroots were introduced we've been having trouble
compiling Go. I've narrowed it down to the path replacement mechanism
that goes on using fixmepath.

For example, this does not work:

  bitbake -c cleansstate go-cross
  bitbake go-cross

But this does:

  bitbake -c cleansstate go-cross
  bitbake -c prepare_recipe_sysroot go-cross
  rm -rf
/home/jenkins/workspace/yoctobuild/build-qemu/tmp/work/x86_64-linux/go-cross/1.7.4-r0/recipe-sysroot-native/usr/lib/go-bootstrap-native-1.4.3
  cp -r
/home/jenkins/workspace/yoctobuild/build-qemu/tmp/sysroots-components/x86_64/go-bootstrap-native/usr/lib/go-bootstrap-native-1.4.3
/home/jenkins/workspace/yoctobuild/build-qemu/tmp/work/x86_64-linux/go-cross/1.7.4-r0/recipe-sysroot-native/usr/lib/go-bootstrap-native-1.4.3
  bitbake go-cross

IOW, if I replace the recipe sysroot with the originals, it works, but
if I keep the modified files put there by the prepare_recipe_sysroot
task, it doesn't.

And this is where I admittedly get a bit lost: I haven't fully
understood how the fixmepath mechanism operates, but from what I can
tell, this path replacement is not appropriate for Go. It doesn't care
where it's installed, and always operates relative to the GOROOT
environment variable, which is set by all Go recipes.

Why the path replacement triggers an error I cannot say, but I suspect
it has to do with the fact that Go object files are a bit special
compared to C object files, and this operation in fact corrupts them.
More mysterious still is why this happens only on some build machines,
and not others, but once triggered it appears to be consistently triggered.

Any advice for what to do next? I could try to skip the fixmepath
operation completely, but I'm not sure how, and it feels a bit like
using a sledgehammer where I should be using a scalpel.

Any help appreciated!

-- 
Kristian



More information about the Openembedded-core mailing list