[yocto] ASSUME_PROVIDED, cmake-native and why cmake is subsequently not found?

[Richard Purdie]

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