On Thu, 2019-04-25 at 08:32 -0400, Robert P. J. Day wrote: > On Thu, 25 Apr 2019, Bach, Pascal wrote: > > > > 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/# > > that *sort of* sounds like what is happening, but to be pedantic, > it's not that cmake can't find binaries in hosttools, it's that > *other* packages can't locate cmake on the host even after setting > > ASSUME_PROVIDED += "cmake-native"
Setting that "fixes" dependencies but it doesn't make cmake visible in our HOSTTOOLS. > i am assuming that whatever search path is used for "native" tools is > extended by the use of ASSUME_PROVIDED -- is that what your patch is > addressing? How would it know in general terms which binaries a given X would provide? > in any event, i've now run into a couple other packages > with the same issue -- "cmake: command not found" -- libcomps-native > and librepo-native, so i'll just ASSUME_PROVIDED them too for the > moment, as they're both installed on my host. This is a bad idea and you're on a path to madness ;-) Cheers, Richard -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
