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.pur...@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.ashfi...@gmail.com> wrote:
> > > >
> > > > On Mon, Aug 30, 2021 at 4:55 PM Andrey Zhizhikin <andre...@gmail.com>
> > > > wrote:
> > > > >
> > > > > Hello Richard,
> > > > >
> > > > > On Mon, Aug 30, 2021 at 10:30 PM Richard Purdie
> > > > > <richard.pur...@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 <andre...@gmail.com>
> > > > > > > Cc: Bruce Ashfield <bruce.ashfi...@gmail.com>
> > > > > > > Cc: Alexander Kanavin <alex.kana...@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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155522):
https://lists.openembedded.org/g/openembedded-core/message/155522
Mute This Topic: https://lists.openembedded.org/mt/85260468/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
