On Tue, Aug 31, 2021 at 3:41 PM Richard Purdie <[email protected]> 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 <[email protected]> > > wrote: > > > > > > On Tue, Aug 31, 2021 at 2:19 PM Richard Purdie > > > <[email protected]> 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 > > > > > <[email protected]> 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 > > > > > > > <[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? > > > > > > > > > > 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.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155531): https://lists.openembedded.org/g/openembedded-core/message/155531 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]] -=-=-=-=-=-=-=-=-=-=-=-
