[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