I am trying to understand why you would use a *-native* version of a recipe.
My understanding is that you would use say openssl-native as a DEPENDS for a recipe if the recipe is using openssl for a step that doesn't require openssl to be built for the target machine. For example say signing an artifact built by the recipe which is independent of the target machine architecture, but needs to be able to run on the host machine natively. And since its built for the host build machine, it won't get included in the target machine image. If the recipe then invokes openssl, I am guessing bitbake is smart enough to run the openssl that was compiled for the host when building the package and not say the openssl actually present on the host. I couldn't find anything in https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html that describes *-native. *Is this documented somewhere? I ran into trouble building a package that depended on glib-2.0. I had to include both glib-2.0 as well as glib-2.0-native to get the package to build successfully consistently - it succeeded sometimes but failed other times. I see other people have had similar issues ( http://lists.openembedded.org/pipermail/openembedded-core/2017-January/132067.html) where they have had to include both glib-2.0 and also glib-2.0-native even though glib-2.0 depends on glib-2.0-native ( https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/glib-2.0/glib.inc?h=pyro#n22). I am guessing its a problem with the glib-2.0 recipe? Thanks, Anoop
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto