On Tue, 2021-08-31 at 13:54 +0200, Andrey Zhizhikin wrote:

Hello Richard,

On Tue, Aug 31, 2021 at 12:03 PM Richard Purdie
[off-list ref] wrote:

quoted

On Tue, 2021-08-31 at 11:53 +0200, Andrey Zhizhikin wrote:

quoted

Hello Bruce,

On Mon, Aug 30, 2021 at 11:12 PM Bruce Ashfield
[off-list ref] wrote:

quoted

On Mon, Aug 30, 2021 at 4:55 PM Andrey Zhizhikin [off-list ref] wrote:

quoted

Hello Richard,

On Mon, Aug 30, 2021 at 10:30 PM Richard Purdie
[off-list ref] wrote:

quoted

On Mon, 2021-08-30 at 20:05 +0000, Andrey Zhizhikin wrote:

quoted

Kernel commit 12dd461ebd19 ("crypto: arm64 - generate *.S by Perl at
build time instead of shipping them") uses perl to generate assembler
files for crypto functionality, which relies on the integer.pm module to
be provided.

Add this module to FILES and export it for build system.

Signed-off-by: Andrey Zhizhikin <redacted>
Cc: Bruce Ashfield <redacted>
Cc: Alexander Kanavin <redacted>
---
 meta/recipes-devtools/perl/perl_5.34.0.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/perl/perl_5.34.0.bb b/meta/recipes-devtools/perl/perl_5.34.0.bb
index ab19a8d0be0..7a07b3f4911 100644
--- a/meta/recipes-devtools/perl/perl_5.34.0.bb
+++ b/meta/recipes-devtools/perl/perl_5.34.0.bb

@@ -248,6 +248,7 @@ FILES:${PN} = "${bindir}/perl ${bindir}/perl.real ${bindir}/perl${PV} ${libdir}/
                ${libdir}/perl5/${PV}/strict.pm \
                ${libdir}/perl5/${PV}/warnings.pm \
                ${libdir}/perl5/${PV}/warnings \
+               ${libdir}/perl5/${PV}/integer.pm \
                ${libdir}/perl5/${PV}/vars.pm \
                ${libdir}/perl5/site_perl \
                ${libdir}/perl5/${PV}/ExtUtils/MANIFEST.SKIP \

Doesn't that mean something is missing an RDEPENDS on perl-module-integer rather
than adding to the main perl package?

Good point! Now that I look at it - this does look a bit too intrusive
(even though it did serve the purpose).

I'm just not sure if I can craft it to RDEPENDS in kernel class instead...

This is definitely required by newer kernel builds (>= 5.14), but I'm
no expert in how those dependencies are set in kernel class. Would
need to look a bit deeper there.

Doing it consistently is the challenge, so we tend to not set them in
the classes themselves.

Understood. Now I see the reason why I didn't observe any of those
dependencies in the kernel classes themselves.

quoted

You have to check both the architecture and the version for many of
the depends/rdepends.

Which is why I tend to carry dependencies like this in the individual
recipes, since the version is known and the arch is an easy check.

This is not a problem for me, as I can add it to the layer kernel
recipe. What I believe the problem might be is that after kernel
migration, eventually all BSP layers would have the same RDEPENDS
defined in their respective kernel recipes. This does call for some
unification imho, but I'm not sure how this can be properly done.

The other thing here is: the same Perl module would be required in the
SDK in order to build Kernels >= 5.14 standalone.
I was planning to include it into RDEPENDS of
nativesdk-packagegroup-sdk-host, but contemplating now if this is a
proper way of doing it. I see that the package group contains flex and
bison for kernel builds, so adding perl integer module there seems
quite logical to me. Unless there are good reasons not to do it this
way.

Isn't the kernel-devsrc recipe the place this should be added? You'd need that
to be building the kernel on target?

This is needed to build kernel on the host using standalone SDK.

To my knowledge, Perl (as a base package) is already provided in the
SDK, but required module is not. This makes the tooling incomplete and
breaks the build when kernel is upgraded to latest versions.

I've just tried it, and adding it to kernel-devsrc did not solve the
missing module issue.

As far as I recall we don't include perl in our SDKs and rely on the one from
the host. Which SDK exactly are you using?

Cheers,

Richard