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"

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? 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.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                         http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
-- 
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to