[yocto] out of tree module dependencies

[RUSSELL PETERSON]

I have been debugging this issue and could use some advice.

The basic issue I see is that do_make_scripts executes and fails. I have seen different fails but in the end it all comes back to something being required in recipe-sysroot or recipe-sysroot-native and it's not there. For instance gcc-cross-aarch64 is missing from recipe-sysroot-native.

Yocto build dependencies is a rather advanced topic and I certainly don't feel I understand exactly what the issue is... but here is my guess.

1. I changed my linux kernel recipe.
2. Because of #1, the cross compiler decided to rebuild. Generally, this isn't an issue. In fact the old cross compiler should *still* be in recipe-sysroot-native.
3. Once the kernel build artifacts is done... my module recipes fire. The first thing they want to do is run do_cve_check.
4. This is the part that causes the problem... do_cve_check DELETES gcc-cross-aarch64 from the sysroot! This is because it cannot find gcc-cross-aarch64.complete... which points to a manifest file. I think this manifest file is created by the gcc-cross-aarch64.do_populate_sysroot. Problem is, cve_check does not depend on that?

This race condition does not always present itself so I am running tests... my solution?

do_cve_check[depends] += "${PN}:do_prepare_recipe_sysroot"

I do that because I believe do_prepare_recipe_sysroot already depends on whatever is required in the recipe-sysroot dirs so it's a more general fix.

Does this make sense to anyone?

> On April 3, 2018 at 7:42 PM Russell Peterson <bluehills7 at comcast.net> wrote:
>
>
> Hello,
>
> I have some out of tree modules that I have added to my custom meta layer.
> Normally things work fine, however, when I modify these recipes every now and then the do_configure fails because the recipe_sysroot directory is not populated. This seems related to the kernel-build-artifacts and the make_scripts task as well but I can’t quite figure it out. Seems like the prepare_recipe_sysroot should execute but in these cases it does not.
>
> I realize I didn’t provide much info here but anyone see something like this before? I do have an unpack_extra task as well that may somehow be related?
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180410/8b4c0622/attachment.html>