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 > <[email protected]> wrote: > > > > On Mon, Aug 30, 2021 at 4:55 PM Andrey Zhizhikin <[email protected]> wrote: > > > > > > Hello Richard, > > > > > > On Mon, Aug 30, 2021 at 10:30 PM Richard Purdie > > > <[email protected]> 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 <[email protected]> > > > > > Cc: Bruce Ashfield <[email protected]> > > > > > Cc: Alexander Kanavin <[email protected]> > > > > > --- > > > > > 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155520): https://lists.openembedded.org/g/openembedded-core/message/155520 Mute This Topic: https://lists.openembedded.org/mt/85260468/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
