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