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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
