> currently trying to build a "core-image-minimal" for a zedboard on my > wholly unsupported fedora 30 (branched) system, so i'm well aware there > will almost certainly be breakage as i try to resolve version numbers and so > on, but working off the "thud" branch, the first issue i had was trying to > configure cmake-native -- the error message is exactly what you can read > someone asking about here: > > https://stackoverflow.com/questions/52663287/glibcxx-3-4-26-not-found > > /home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/cmake- > native/3.12.2-r0/build/Bootstrap.cmk/cmake: > /home/rpjday/oe/builds/zedboard/tmp/sysroots-uninative/x86_64- > linux/usr/lib/libstdc++.so.6: > version `GLIBCXX_3.4.26' not found (required by > /home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/cmake- > native/3.12.2-r0/build/Bootstrap.cmk/cmake) > | --------------------------------------------- > | Error when bootstrapping CMake: > | Problem while running initial CMake > | --------------------------------------------- > > i'm unsure how to resolve that easily, but my first reaction was, "if i > already > have cmake installed on the host, why not just take advantage of > ASSUME_PROVIDED"? i recall from some time back asking why more host > utils were not, by default, included in ASSUME_PROVIDED, and the answer > (quite reasonably) was that one wants to have as few variables as possible > for reliably replicated builds. > > fair enough, but in my case, until i figure out how to fix that, i thought, > why > not just: > > ASSUME_PROVIDED += "cmake-native" > > so i did, and that got me past the cmake-native build issue, until i hit this > trying to build libsolv-native: > > DEBUG: Executing shell function do_configure > /home/rpjday/oe/builds/zedboard/tmp/work/x86_64-linux/libsolv- > native/0.6.35-r0/temp/run.do_configure.16705: > line 130: cmake: command not found > > hang on ... why would a subsequent recipe not be able to locate > /usr/bin/cmake on my host after i explicitly identified cmake-native as > assumed to be provided? is there something about the libsolv-native recipe > that does not take that possibility into account? i'm just about to check, > but if > someone has an explanation for that, i'm all ears.
There is an issue that CMake is not able to find binaries in hosttools. It might be the case that this is the issue you are seeing. I submitted a patch for that but I'm not sure it Ever made it into master or a release. I need to follow up on this, the patch is here: https://patchwork.openembedded.org/series/14429/# > finally, regarding ASSUME_PROVIDED, given that i'm already living life > dangerously with an unsupported distro, is there any harm in just loading up > on ASSUME_PROVIDED packages, as long as they work? in many cases, i can > see that the version that would be built by YP is close to, if not identical > to, > my host version. so other than risking breakage down the line as versions > change, as long as the host packages work, is there any harm in just taking > advantage of them? > Generally it's find to use ASSUME_PROVIDED if you don't mind the dependency between the build host and Yocto. Pascal -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
