On Thu, 2019-04-25 at 08:05 -0400, Robert P. J. Day wrote: > (warning: i've been away from YP for well over a year and am now > studiously trying to catch up, so i have some work to do.) > > 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 > > ---------------------------------------------
This probably means that your system c library is newer than the one in uninative and things aren't working because of that. Either try: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=5f6156b32c9d17bdb06d67199373433b0e470cc7 or turning off uninative. > 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. That is one reason, there is a second. We patch some of the utilities to do what we need. We rely on our patches being present. > fair enough, but in my case, until i figure out how to fix that, i > thought, why not just: > > ASSUME_PROVIDED += "cmake-native" This is a bad idea as we patch cmake iirc. > > 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. You would also have to do: HOSTTOOLS += "cmake" to allow cmake to be visible from the host system. Its a host contamination protection mechanisn that has been there since pyro. > 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? I think it will be a world of pain ;-) Cheers, Richard -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
