[OE-core][PATCH] perl: add integer module required for kernel >= 5.14

[OE-core][PATCH] perl: add integer module required for kernel >= 5.14

[Andrey Zhizhikin]

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 <andrey.z@gmail.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: Alexander Kanavin <alex.kanavin@gmail.com>
---
 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 \
-- 
2.17.1

Re: [OE-core][PATCH] perl: add integer module required for kernel >= 5.14

[Richard Purdie]

On Mon, 2021-08-30 at 20:05 +0000, Andrey Zhizhikin wrote:
> 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 <andrey.z@gmail.com>
> Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
> Cc: Alexander Kanavin <alex.kanavin@gmail.com>
> ---
>  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?

Cheers,

Richard

Re: [OE-core][PATCH] perl: add integer module required for kernel >= 5.14

[Andrey Zhizhikin]

Hello Richard,

On Mon, Aug 30, 2021 at 10:30 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Mon, 2021-08-30 at 20:05 +0000, Andrey Zhizhikin wrote:
> > 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 <andrey.z@gmail.com>
> > Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
> > Cc: Alexander Kanavin <alex.kanavin@gmail.com>
> > ---
> >  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.

>
> Cheers,
>
> Richard
>

--
Regards,
Andrey.

Re: [OE-core][PATCH] perl: add integer module required for kernel >= 5.14

[Bruce Ashfield]

On Mon, Aug 30, 2021 at 4:55 PM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
>
> Hello Richard,
>
> On Mon, Aug 30, 2021 at 10:30 PM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > On Mon, 2021-08-30 at 20:05 +0000, Andrey Zhizhikin wrote:
> > > 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 <andrey.z@gmail.com>
> > > Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > Cc: Alexander Kanavin <alex.kanavin@gmail.com>
> > > ---
> > >  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.

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.

I had some roughed out patches to start moving some of the
dependencies into the classes, just to make creating custom recipes a
bit easier, but I didn't complete them to my satisfaction and can't
see to track them down at the moment.

Bruce

>
> >
> > Cheers,
> >
> > Richard
> >
>
> --
> Regards,
> Andrey.



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [OE-core][PATCH] perl: add integer module required for kernel >= 5.14

[Andrey Zhizhikin]

Hello Bruce,

On Mon, Aug 30, 2021 at 11:12 PM Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
>
> On Mon, Aug 30, 2021 at 4:55 PM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
> >
> > Hello Richard,
> >
> > On Mon, Aug 30, 2021 at 10:30 PM Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > >
> > > On Mon, 2021-08-30 at 20:05 +0000, Andrey Zhizhikin wrote:
> > > > 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 <andrey.z@gmail.com>
> > > > Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > > Cc: Alexander Kanavin <alex.kanavin@gmail.com>
> > > > ---
> > > >  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.

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

>
> I had some roughed out patches to start moving some of the
> dependencies into the classes, just to make creating custom recipes a
> bit easier, but I didn't complete them to my satisfaction and can't
> see to track them down at the moment.
>
> Bruce
>
> >
> > >
> > > Cheers,
> > >
> > > Richard
> > >
> >
> > --
> > Regards,
> > Andrey.
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II



-- 
Regards,
Andrey.

Re: [OE-core][PATCH] perl: add integer module required for kernel >= 5.14

[Richard Purdie]

On Tue, 2021-08-31 at 11:53 +0200, Andrey Zhizhikin wrote:
> Hello Bruce,
> 
> On Mon, Aug 30, 2021 at 11:12 PM Bruce Ashfield
> <bruce.ashfield@gmail.com> wrote:
> > 
> > On Mon, Aug 30, 2021 at 4:55 PM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
> > > 
> > > Hello Richard,
> > > 
> > > On Mon, Aug 30, 2021 at 10:30 PM Richard Purdie
> > > <richard.purdie@linuxfoundation.org> wrote:
> > > > 
> > > > On Mon, 2021-08-30 at 20:05 +0000, Andrey Zhizhikin wrote:
> > > > > 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 <andrey.z@gmail.com>
> > > > > Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > > > Cc: Alexander Kanavin <alex.kanavin@gmail.com>
> > > > > ---
> > > > >  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.
> 
> > 
> > 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?

Cheers,

Richard

Re: [OE-core][PATCH] perl: add integer module required for kernel >= 5.14

[Andrey Zhizhikin]

Hello Richard,

On Tue, Aug 31, 2021 at 12:03 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Tue, 2021-08-31 at 11:53 +0200, Andrey Zhizhikin wrote:
> > Hello Bruce,
> >
> > On Mon, Aug 30, 2021 at 11:12 PM Bruce Ashfield
> > <bruce.ashfield@gmail.com> wrote:
> > >
> > > On Mon, Aug 30, 2021 at 4:55 PM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
> > > >
> > > > Hello Richard,
> > > >
> > > > On Mon, Aug 30, 2021 at 10:30 PM Richard Purdie
> > > > <richard.purdie@linuxfoundation.org> wrote:
> > > > >
> > > > > On Mon, 2021-08-30 at 20:05 +0000, Andrey Zhizhikin wrote:
> > > > > > 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 <andrey.z@gmail.com>
> > > > > > Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > > > > Cc: Alexander Kanavin <alex.kanavin@gmail.com>
> > > > > > ---
> > > > > >  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.
> >
> > >
> > > 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.

>
> Cheers,
>
> Richard
>


--
Regards,
Andrey.

Re: [OE-core][PATCH] perl: add integer module required for kernel >= 5.14

[Richard Purdie]

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
> <richard.purdie@linuxfoundation.org> wrote:
> > 
> > On Tue, 2021-08-31 at 11:53 +0200, Andrey Zhizhikin wrote:
> > > Hello Bruce,
> > > 
> > > On Mon, Aug 30, 2021 at 11:12 PM Bruce Ashfield
> > > <bruce.ashfield@gmail.com> wrote:
> > > > 
> > > > On Mon, Aug 30, 2021 at 4:55 PM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
> > > > > 
> > > > > Hello Richard,
> > > > > 
> > > > > On Mon, Aug 30, 2021 at 10:30 PM Richard Purdie
> > > > > <richard.purdie@linuxfoundation.org> wrote:
> > > > > > 
> > > > > > On Mon, 2021-08-30 at 20:05 +0000, Andrey Zhizhikin wrote:
> > > > > > > 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 <andrey.z@gmail.com>
> > > > > > > Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > > > > > Cc: Alexander Kanavin <alex.kanavin@gmail.com>
> > > > > > > ---
> > > > > > >  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.
> > > 
> > > > 
> > > > 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

Re: [OE-core][PATCH] perl: add integer module required for kernel >= 5.14

[Andrey Zhizhikin]

On Tue, Aug 31, 2021 at 2:19 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> 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
> > <richard.purdie@linuxfoundation.org> wrote:
> > >
> > > On Tue, 2021-08-31 at 11:53 +0200, Andrey Zhizhikin wrote:
> > > > Hello Bruce,
> > > >
> > > > On Mon, Aug 30, 2021 at 11:12 PM Bruce Ashfield
> > > > <bruce.ashfield@gmail.com> wrote:
> > > > >
> > > > > On Mon, Aug 30, 2021 at 4:55 PM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
> > > > > >
> > > > > > Hello Richard,
> > > > > >
> > > > > > On Mon, Aug 30, 2021 at 10:30 PM Richard Purdie
> > > > > > <richard.purdie@linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > On Mon, 2021-08-30 at 20:05 +0000, Andrey Zhizhikin wrote:
> > > > > > > > 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 <andrey.z@gmail.com>
> > > > > > > > Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > > > > > > Cc: Alexander Kanavin <alex.kanavin@gmail.com>
> > > > > > > > ---
> > > > > > > >  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.
> > > >
> > > > >
> > > > > 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?

This is then rather strange and confusing...

I do generate standalone SDK via 'bitbake meta-toolchain', which to my
current understanding should pull only minimal set of toolchain
component into its content. This does include Perl, perhaps through
some dependency resolution.

Since I use distro from meta-freescale layer - it might be (but less
likely) coming from some dependencies inside of it... I can try to
generate it off Poky distro now to see if it has Perl inside as well.

>
> Cheers,
>
> Richard
>


-- 
Regards,
Andrey.

Re: [OE-core][PATCH] perl: add integer module required for kernel >= 5.14

[Andrey Zhizhikin]

Richard,

On Tue, Aug 31, 2021 at 2:29 PM Andrey Zhizhikin via
lists.openembedded.org <andrey.z=gmail.com@lists.openembedded.org>
wrote:
>
> On Tue, Aug 31, 2021 at 2:19 PM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > 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
> > > <richard.purdie@linuxfoundation.org> wrote:
> > > >
> > > > On Tue, 2021-08-31 at 11:53 +0200, Andrey Zhizhikin wrote:
> > > > > Hello Bruce,
> > > > >
> > > > > On Mon, Aug 30, 2021 at 11:12 PM Bruce Ashfield
> > > > > <bruce.ashfield@gmail.com> wrote:
> > > > > >
> > > > > > On Mon, Aug 30, 2021 at 4:55 PM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
> > > > > > >
> > > > > > > Hello Richard,
> > > > > > >
> > > > > > > On Mon, Aug 30, 2021 at 10:30 PM Richard Purdie
> > > > > > > <richard.purdie@linuxfoundation.org> wrote:
> > > > > > > >
> > > > > > > > On Mon, 2021-08-30 at 20:05 +0000, Andrey Zhizhikin wrote:
> > > > > > > > > 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 <andrey.z@gmail.com>
> > > > > > > > > Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > > > > > > > Cc: Alexander Kanavin <alex.kanavin@gmail.com>
> > > > > > > > > ---
> > > > > > > > >  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.
> > > > >
> > > > > >
> > > > > > 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?
>
> This is then rather strange and confusing...
>
> I do generate standalone SDK via 'bitbake meta-toolchain', which to my
> current understanding should pull only minimal set of toolchain
> component into its content. This does include Perl, perhaps through
> some dependency resolution.
>
> Since I use distro from meta-freescale layer - it might be (but less
> likely) coming from some dependencies inside of it... I can try to
> generate it off Poky distro now to see if it has Perl inside as well.

Just to follow-up on this: nativesdk-perl and a bunch of modules are
pulled into the SDK by autoconf, which lists them in it's RDEPENDS.

This behavior is distro-agnostic, and making Perl to be installed into
SDK in any case.

>
> >
> > Cheers,
> >
> > Richard
> >
>
>
> --
> Regards,
> Andrey.
>
> 
>


-- 
Regards,
Andrey.

Re: [OE-core][PATCH] perl: add integer module required for kernel >= 5.14

[Richard Purdie]

On Tue, 2021-08-31 at 15:26 +0200, Andrey Zhizhikin wrote:
> Richard,
> 
> On Tue, Aug 31, 2021 at 2:29 PM Andrey Zhizhikin via
> lists.openembedded.org <andrey.z=gmail.com@lists.openembedded.org>
> wrote:
> > 
> > On Tue, Aug 31, 2021 at 2:19 PM Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > > 
> > > 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
> > > > <richard.purdie@linuxfoundation.org> wrote:
> > > > > 
> > > > > On Tue, 2021-08-31 at 11:53 +0200, Andrey Zhizhikin wrote:
> > > > > > Hello Bruce,
> > > > > > 
> > > > > > On Mon, Aug 30, 2021 at 11:12 PM Bruce Ashfield
> > > > > > <bruce.ashfield@gmail.com> wrote:
> > > > > > > 
> > > > > > > On Mon, Aug 30, 2021 at 4:55 PM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
> > > > > > > > 
> > > > > > > > Hello Richard,
> > > > > > > > 
> > > > > > > > On Mon, Aug 30, 2021 at 10:30 PM Richard Purdie
> > > > > > > > <richard.purdie@linuxfoundation.org> wrote:
> > > > > > > > > 
> > > > > > > > > On Mon, 2021-08-30 at 20:05 +0000, Andrey Zhizhikin wrote:
> > > > > > > > > > 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 <andrey.z@gmail.com>
> > > > > > > > > > Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > > > > > > > > Cc: Alexander Kanavin <alex.kanavin@gmail.com>
> > > > > > > > > > ---
> > > > > > > > > >  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.
> > > > > > 
> > > > > > > 
> > > > > > > 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?
> > 
> > This is then rather strange and confusing...
> > 
> > I do generate standalone SDK via 'bitbake meta-toolchain', which to my
> > current understanding should pull only minimal set of toolchain
> > component into its content. This does include Perl, perhaps through
> > some dependency resolution.
> > 
> > Since I use distro from meta-freescale layer - it might be (but less
> > likely) coming from some dependencies inside of it... I can try to
> > generate it off Poky distro now to see if it has Perl inside as well.
> 
> Just to follow-up on this: nativesdk-perl and a bunch of modules are
> pulled into the SDK by autoconf, which lists them in it's RDEPENDS.
> 
> This behavior is distro-agnostic, and making Perl to be installed into
> SDK in any case.

I had a further look and I think I'm confusing nativesdk-buildtools-perl-dummy
which is included in buildtool-tarball and nativesdk-sdk-provides-dummy which is
included in wider SDKs. The latter excludes things like bash and env but not
perl. Just to help confuse things, target-sdk-provides-dummy does exclude perl.

I guess that brings us back to nativesdk-packagegroup-sdk-host as the place
these things are listed (and where autoconf comes from).

Cheers,

Richard

Re: [OE-core][PATCH] perl: add integer module required for kernel >= 5.14

[Andrey Zhizhikin]

On Tue, Aug 31, 2021 at 3:41 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Tue, 2021-08-31 at 15:26 +0200, Andrey Zhizhikin wrote:
> > Richard,
> >
> > On Tue, Aug 31, 2021 at 2:29 PM Andrey Zhizhikin via
> > lists.openembedded.org <andrey.z=gmail.com@lists.openembedded.org>
> > wrote:
> > >
> > > On Tue, Aug 31, 2021 at 2:19 PM Richard Purdie
> > > <richard.purdie@linuxfoundation.org> wrote:
> > > >
> > > > 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
> > > > > <richard.purdie@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Tue, 2021-08-31 at 11:53 +0200, Andrey Zhizhikin wrote:
> > > > > > > Hello Bruce,
> > > > > > >
> > > > > > > On Mon, Aug 30, 2021 at 11:12 PM Bruce Ashfield
> > > > > > > <bruce.ashfield@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Aug 30, 2021 at 4:55 PM Andrey Zhizhikin <andrey.z@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Hello Richard,
> > > > > > > > >
> > > > > > > > > On Mon, Aug 30, 2021 at 10:30 PM Richard Purdie
> > > > > > > > > <richard.purdie@linuxfoundation.org> wrote:
> > > > > > > > > >
> > > > > > > > > > On Mon, 2021-08-30 at 20:05 +0000, Andrey Zhizhikin wrote:
> > > > > > > > > > > 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 <andrey.z@gmail.com>
> > > > > > > > > > > Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > > > > > > > > > Cc: Alexander Kanavin <alex.kanavin@gmail.com>
> > > > > > > > > > > ---
> > > > > > > > > > >  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.
> > > > > > >
> > > > > > > >
> > > > > > > > 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?
> > >
> > > This is then rather strange and confusing...
> > >
> > > I do generate standalone SDK via 'bitbake meta-toolchain', which to my
> > > current understanding should pull only minimal set of toolchain
> > > component into its content. This does include Perl, perhaps through
> > > some dependency resolution.
> > >
> > > Since I use distro from meta-freescale layer - it might be (but less
> > > likely) coming from some dependencies inside of it... I can try to
> > > generate it off Poky distro now to see if it has Perl inside as well.
> >
> > Just to follow-up on this: nativesdk-perl and a bunch of modules are
> > pulled into the SDK by autoconf, which lists them in it's RDEPENDS.
> >
> > This behavior is distro-agnostic, and making Perl to be installed into
> > SDK in any case.
>
> I had a further look and I think I'm confusing nativesdk-buildtools-perl-dummy
> which is included in buildtool-tarball and nativesdk-sdk-provides-dummy which is
> included in wider SDKs. The latter excludes things like bash and env but not
> perl.

Thanks for tracing it out! I had the same conclusion when I looked at
those package groups and runtime dependencies.

I guess if nativesdk-sdk-provides-dummy would exclude Perl, this might
lead to confusing autoconf and eventually break things, at least my
common sense is telling me so. Therefore, it is OK not to exclude it
via nativesdk-sdk-provides-dummy.

>Just to help confuse things, target-sdk-provides-dummy does exclude perl.
>
> I guess that brings us back to nativesdk-packagegroup-sdk-host as the place
> these things are listed (and where autoconf comes from).

OK, then I would send another patch to have the module included there.
This does sound logical to me, and at least in this case it would be a
bit more transparent why Perl is included in the SDK (in contrary to
the obscured dependency of autoconf).

>
> Cheers,
>
> Richard
>
>
>


-- 
Regards,
Andrey.