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

Robert P. J. Day

(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:

version `GLIBCXX_3.4.26' not found (required by
| ---------------------------------------------
| 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
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.

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?



Robert P. J. Day Ottawa, Ontario, CANADA


Join to automatically receive all group messages.