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

[Richard Purdie]

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