Re: [OE-core] [PATCH 6/6] perf: drop 'include' copy
On Tue, May 26, 2020 at 10:44 PM Martin Jansa wrote:
>
> On Tue, May 26, 2020 at 10:22:07PM +0200, Andrey Zhizhikin wrote:
> > Kernel 4.4 is also LTS and has (had) a very long time span, so I
> > believe there are some people out there who might still have it in
> > their Products (industrial applications are pretty conservative guys).
> > I have to admit that Yocto 3.1 + Kernel 4.4 is a rather strange
> > combination, but it also has a valid reason to exist.
> >
> > I guess reverting this patch is not really an option, but this topic
> > deserves then a bit of documentation somewhere so people can look this
> > up and have a quick fix for themselves. The question is: where to put
> > this information?
> >
> > Honestly, it didn't take me long to find the commit that solved the
> > build, it took me rather long to figure out why I didn't see changes
> > from it on the [dunfell]...
> >
> > >
> > > What exactly was the build error that you saw ?
> >
> > Exactly what JaMa had and fixed with his commit, namely a multitude of:
> > error: #include nested too deeply
> >
> > and some of:
> >
> > /perf/1.0-r9/perf-1.0/tools/include/linux/list.h:5:10: fatal
> > error: ../../../include/linux/list.h: No such file or directory
>
> But this isn't your only issue with perf on 4.4 kernel, right?
>
> I still carry whatever is needed in a .bbappend, for dunfell I have
> also:
>
> # The tools/lib/api in kernels older than 4.8 don't respect WERROR env
> # variable exported by perf.bb
> EXTRA_OEMAKE += "EXTRA_CFLAGS='-ldw -Wno-error=stringop-truncation'"
>
> # scripting PACKAGECONFIG is now using python3, but perf in kernel
> # supports python3 only with 4.17-rc1 and newer kernel (here we are
> # currently using 4.4.84), see:
> #
> http://lists.openembedded.org/pipermail/openembedded-core/2019-September/286902.html
> PACKAGECONFIG_remove = "scripting"
Mine's got only:
PACKAGECONFIG_remove = "scripting"
And now I have in addition:
+PERF_SRC = "Makefile \
+include \
+tools/arch \
+tools/build \
+tools/include \
+tools/lib \
+tools/Makefile \
+tools/perf \
+tools/scripts \
+scripts/ \
+arch/${ARCH}/Makefile \
I guess you can safely drop the -Wno-error=stringop-truncation, it was
fixed with [d943a53ac6d7bd5eab93adecfe9b37356e46da44] in 4.4.y
>
> Maybe some of it got already resolved elsewhere, this bbappend just
> collects whatever tweaks are needed when it gets broken and I very
> rarely have time to go back through them to re-check if it's still
> needed (with newer oe-core revision or slightly newer 4.4 kernel).
>
> Cheers,
--
Regards,
Andrey.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138742):
https://lists.openembedded.org/g/openembedded-core/message/138742
Mute This Topic: https://lists.openembedded.org/mt/72386349/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 6/6] perf: drop 'include' copy
On Tue, May 26, 2020 at 10:22:07PM +0200, Andrey Zhizhikin wrote: > Kernel 4.4 is also LTS and has (had) a very long time span, so I > believe there are some people out there who might still have it in > their Products (industrial applications are pretty conservative guys). > I have to admit that Yocto 3.1 + Kernel 4.4 is a rather strange > combination, but it also has a valid reason to exist. > > I guess reverting this patch is not really an option, but this topic > deserves then a bit of documentation somewhere so people can look this > up and have a quick fix for themselves. The question is: where to put > this information? > > Honestly, it didn't take me long to find the commit that solved the > build, it took me rather long to figure out why I didn't see changes > from it on the [dunfell]... > > > > > What exactly was the build error that you saw ? > > Exactly what JaMa had and fixed with his commit, namely a multitude of: > error: #include nested too deeply > > and some of: > > /perf/1.0-r9/perf-1.0/tools/include/linux/list.h:5:10: fatal > error: ../../../include/linux/list.h: No such file or directory But this isn't your only issue with perf on 4.4 kernel, right? I still carry whatever is needed in a .bbappend, for dunfell I have also: # The tools/lib/api in kernels older than 4.8 don't respect WERROR env # variable exported by perf.bb EXTRA_OEMAKE += "EXTRA_CFLAGS='-ldw -Wno-error=stringop-truncation'" # scripting PACKAGECONFIG is now using python3, but perf in kernel # supports python3 only with 4.17-rc1 and newer kernel (here we are # currently using 4.4.84), see: # http://lists.openembedded.org/pipermail/openembedded-core/2019-September/286902.html PACKAGECONFIG_remove = "scripting" Maybe some of it got already resolved elsewhere, this bbappend just collects whatever tweaks are needed when it gets broken and I very rarely have time to go back through them to re-check if it's still needed (with newer oe-core revision or slightly newer 4.4 kernel). Cheers, signature.asc Description: PGP signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138739): https://lists.openembedded.org/g/openembedded-core/message/138739 Mute This Topic: https://lists.openembedded.org/mt/72386349/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 6/6] perf: drop 'include' copy
On Tue, May 26, 2020 at 2:31 PM Bruce Ashfield wrote:
>
> On Tue, May 26, 2020 at 1:44 AM Andrey Zhizhikin wrote:
> >
> > On Mon, Oct 21, 2019 at 10:58 PM Bruce Ashfield
> > wrote:
> > >
> > > On Mon, Oct 21, 2019 at 4:24 PM Martin Jansa
> > > wrote:
> > > >
> > > > On Mon, Oct 21, 2019 at 04:16:18PM -0400, bruce.ashfi...@gmail.com
> > > > wrote:
> > > > > From: Bruce Ashfield
> > > > >
> > > > > The copy of the kernel's top level include directory is not
> > > > > required to build perf. We have both the linux-libc-headers and
> > > > > perf's captured/copied headers for what it requires.
> > > > >
> > > > > The copy of the kernel's headers is leading us to multiple smaller
> > > > > fixes to ensure that the various .h files are in sync. We can
> > > > > remove the copy and all of the sync checks, and perf still builds
> > > > > and executes correctly.
> > > >
> > > > Maybe reorder this before "[OE-core] [PATCH 3/6] perf: fix v5.4+ builds"
> > > > as it removes most of what was possibly incorrectly added there (see 2nd
> > > > review)
> > > >
> > >
> > > I left this here on purpose, since it is only RFC. The other patches
> > > as they appear in the series are required to build against 5.4+, but
> > > this is optional.
> >
> > Look like this patch causes issues with building perf for 4.4.y kernel...
> >
> > I've recently started to upgrade some of BSPs from zeus to dunfell,
> > and kernel 4.4.y fails to build with this patch applied. When I
> > applied changes from Martin in commit
> > [f3515d2d2545cae6b88fe5e86d081f4ef6133bf6] - build went through.
> >
> > I have now the bbappend in the layer, which sets the PERF_SRC to add
> > the "include" folder back but I don't think this is a clean approach.
> >
> > Should this be reverted, or those who has a "dunfell+4.4.y kernel"
> > setup need to use appends to override the PERF_SRC?
>
> If you revert it, you might be trading warnings and breakages for
> newer kernels to fix 4.4. That's the issue with perf, since it builds
> right from the kernel source, it has to serve many different versions
> (and we juggle breaking/fixing that from time to time).
I got the same conclusion that healing one can hurt the other... perf
is a gentle beast, I had my own history with it already.
>
> So any revert would have to then build all of the different kernel
> versions and perf to make sure that we don't trade one breakage for
> another .. and being LTS we need to be extra careful. Since we don't
> have an active 4.4 kernel in that branch, it would have to be ad-hoc
> testing to confirm.
Kernel 4.4 is also LTS and has (had) a very long time span, so I
believe there are some people out there who might still have it in
their Products (industrial applications are pretty conservative guys).
I have to admit that Yocto 3.1 + Kernel 4.4 is a rather strange
combination, but it also has a valid reason to exist.
I guess reverting this patch is not really an option, but this topic
deserves then a bit of documentation somewhere so people can look this
up and have a quick fix for themselves. The question is: where to put
this information?
Honestly, it didn't take me long to find the commit that solved the
build, it took me rather long to figure out why I didn't see changes
from it on the [dunfell]...
>
> What exactly was the build error that you saw ?
Exactly what JaMa had and fixed with his commit, namely a multitude of:
error: #include nested too deeply
and some of:
/perf/1.0-r9/perf-1.0/tools/include/linux/list.h:5:10: fatal
error: ../../../include/linux/list.h: No such file or directory
>
> Bruce
>
>
>
> Bruce
>
> >
> > >
> > > Bruce
> > >
> > > > > Signed-off-by: Bruce Ashfield
> > > > > ---
> > > > > meta/recipes-kernel/perf/perf.bb | 9 -
> > > > > 1 file changed, 9 deletions(-)
> > > > >
> > > > > diff --git a/meta/recipes-kernel/perf/perf.bb
> > > > > b/meta/recipes-kernel/perf/perf.bb
> > > > > index 191305969c..5f0ba7c180 100644
> > > > > --- a/meta/recipes-kernel/perf/perf.bb
> > > > > +++ b/meta/recipes-kernel/perf/perf.bb
> > > > > @@ -106,7 +106,6 @@ EXTRA_OEMAKE += "\
> > > > > EXTRA_OEMAKE_append_task-configure = " JOBS=1"
> > > > >
> > > > > PERF_SRC ?= "Makefile \
> > > > > - include \
> > > > > tools/arch \
> > > > > tools/build \
> > > > > tools/include \
> > > > > @@ -248,14 +247,6 @@ do_configure_prepend () {
> > > > > # so we copy it from the sysroot unistd.h to the perf unistd.h
> > > > > install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h
> > > > > ${S}/tools/include/uapi/asm-generic/unistd.h
> > > > > install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h
> > > > > ${S}/include/uapi/asm-generic/unistd.h
> > > > > -
> > > > > -# bits.h can have the same issue as unistd.h, so we make the
> > > > > tools variant take precedence
> > > > > -[ -e ${S}/tools/include/linux/bits.h ] && install -D -m0644
> > > > > ${S}/tools/include/linux/bits.h ${S}/inclu
Re: [OE-core] [PATCH 6/6] perf: drop 'include' copy
On Tue, May 26, 2020 at 1:44 AM Andrey Zhizhikin wrote:
>
> On Mon, Oct 21, 2019 at 10:58 PM Bruce Ashfield
> wrote:
> >
> > On Mon, Oct 21, 2019 at 4:24 PM Martin Jansa wrote:
> > >
> > > On Mon, Oct 21, 2019 at 04:16:18PM -0400, bruce.ashfi...@gmail.com wrote:
> > > > From: Bruce Ashfield
> > > >
> > > > The copy of the kernel's top level include directory is not
> > > > required to build perf. We have both the linux-libc-headers and
> > > > perf's captured/copied headers for what it requires.
> > > >
> > > > The copy of the kernel's headers is leading us to multiple smaller
> > > > fixes to ensure that the various .h files are in sync. We can
> > > > remove the copy and all of the sync checks, and perf still builds
> > > > and executes correctly.
> > >
> > > Maybe reorder this before "[OE-core] [PATCH 3/6] perf: fix v5.4+ builds"
> > > as it removes most of what was possibly incorrectly added there (see 2nd
> > > review)
> > >
> >
> > I left this here on purpose, since it is only RFC. The other patches
> > as they appear in the series are required to build against 5.4+, but
> > this is optional.
>
> Look like this patch causes issues with building perf for 4.4.y kernel...
>
> I've recently started to upgrade some of BSPs from zeus to dunfell,
> and kernel 4.4.y fails to build with this patch applied. When I
> applied changes from Martin in commit
> [f3515d2d2545cae6b88fe5e86d081f4ef6133bf6] - build went through.
>
> I have now the bbappend in the layer, which sets the PERF_SRC to add
> the "include" folder back but I don't think this is a clean approach.
>
> Should this be reverted, or those who has a "dunfell+4.4.y kernel"
> setup need to use appends to override the PERF_SRC?
If you revert it, you might be trading warnings and breakages for
newer kernels to fix 4.4. That's the issue with perf, since it builds
right from the kernel source, it has to serve many different versions
(and we juggle breaking/fixing that from time to time).
So any revert would have to then build all of the different kernel
versions and perf to make sure that we don't trade one breakage for
another .. and being LTS we need to be extra careful. Since we don't
have an active 4.4 kernel in that branch, it would have to be ad-hoc
testing to confirm.
What exactly was the build error that you saw ?
Bruce
Bruce
>
> >
> > Bruce
> >
> > > > Signed-off-by: Bruce Ashfield
> > > > ---
> > > > meta/recipes-kernel/perf/perf.bb | 9 -
> > > > 1 file changed, 9 deletions(-)
> > > >
> > > > diff --git a/meta/recipes-kernel/perf/perf.bb
> > > > b/meta/recipes-kernel/perf/perf.bb
> > > > index 191305969c..5f0ba7c180 100644
> > > > --- a/meta/recipes-kernel/perf/perf.bb
> > > > +++ b/meta/recipes-kernel/perf/perf.bb
> > > > @@ -106,7 +106,6 @@ EXTRA_OEMAKE += "\
> > > > EXTRA_OEMAKE_append_task-configure = " JOBS=1"
> > > >
> > > > PERF_SRC ?= "Makefile \
> > > > - include \
> > > > tools/arch \
> > > > tools/build \
> > > > tools/include \
> > > > @@ -248,14 +247,6 @@ do_configure_prepend () {
> > > > # so we copy it from the sysroot unistd.h to the perf unistd.h
> > > > install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h
> > > > ${S}/tools/include/uapi/asm-generic/unistd.h
> > > > install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h
> > > > ${S}/include/uapi/asm-generic/unistd.h
> > > > -
> > > > -# bits.h can have the same issue as unistd.h, so we make the tools
> > > > variant take precedence
> > > > -[ -e ${S}/tools/include/linux/bits.h ] && install -D -m0644
> > > > ${S}/tools/include/linux/bits.h ${S}/include/linux/bits.h
> > > > -
> > > > -[ -e ${S}/tools/perf/util/include/linux/ctype.h ] && install -D
> > > > -m0644 ${S}/include/linux/ctype.h
> > > > ${S}/tools/perf/util/include/linux/ctype.h
> > > > -
> > > > -[ -e ${S}/include/uapi/linux/kvm.h ] && install -D -m0644
> > > > ${S}/include/uapi/linux/kvm.h ${S}/tools/include/uapi/linux/kvm.h
> > > > -[ -e ${S}/include/uapi/linux/sched.h ] && install -D -m0644
> > > > ${S}/include/uapi/linux/sched.h ${S}/tools/include/uapi/linux/sched.h
> > > > }
> > > >
> > > > python do_package_prepend() {
> > > > --
> > > > 2.19.1
> > > >
> > > > --
> > > > ___
> > > > Openembedded-core mailing list
> > > > Openembedded-core@lists.openembedded.org
> > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > >
> > > --
> > > Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
> >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
> --
> Regards,
> Andrey.
--
- Thou shalt not follow the NULL
Re: [OE-core] [PATCH 6/6] perf: drop 'include' copy
On Mon, Oct 21, 2019 at 10:58 PM Bruce Ashfield
wrote:
>
> On Mon, Oct 21, 2019 at 4:24 PM Martin Jansa wrote:
> >
> > On Mon, Oct 21, 2019 at 04:16:18PM -0400, bruce.ashfi...@gmail.com wrote:
> > > From: Bruce Ashfield
> > >
> > > The copy of the kernel's top level include directory is not
> > > required to build perf. We have both the linux-libc-headers and
> > > perf's captured/copied headers for what it requires.
> > >
> > > The copy of the kernel's headers is leading us to multiple smaller
> > > fixes to ensure that the various .h files are in sync. We can
> > > remove the copy and all of the sync checks, and perf still builds
> > > and executes correctly.
> >
> > Maybe reorder this before "[OE-core] [PATCH 3/6] perf: fix v5.4+ builds"
> > as it removes most of what was possibly incorrectly added there (see 2nd
> > review)
> >
>
> I left this here on purpose, since it is only RFC. The other patches
> as they appear in the series are required to build against 5.4+, but
> this is optional.
Look like this patch causes issues with building perf for 4.4.y kernel...
I've recently started to upgrade some of BSPs from zeus to dunfell,
and kernel 4.4.y fails to build with this patch applied. When I
applied changes from Martin in commit
[f3515d2d2545cae6b88fe5e86d081f4ef6133bf6] - build went through.
I have now the bbappend in the layer, which sets the PERF_SRC to add
the "include" folder back but I don't think this is a clean approach.
Should this be reverted, or those who has a "dunfell+4.4.y kernel"
setup need to use appends to override the PERF_SRC?
>
> Bruce
>
> > > Signed-off-by: Bruce Ashfield
> > > ---
> > > meta/recipes-kernel/perf/perf.bb | 9 -
> > > 1 file changed, 9 deletions(-)
> > >
> > > diff --git a/meta/recipes-kernel/perf/perf.bb
> > > b/meta/recipes-kernel/perf/perf.bb
> > > index 191305969c..5f0ba7c180 100644
> > > --- a/meta/recipes-kernel/perf/perf.bb
> > > +++ b/meta/recipes-kernel/perf/perf.bb
> > > @@ -106,7 +106,6 @@ EXTRA_OEMAKE += "\
> > > EXTRA_OEMAKE_append_task-configure = " JOBS=1"
> > >
> > > PERF_SRC ?= "Makefile \
> > > - include \
> > > tools/arch \
> > > tools/build \
> > > tools/include \
> > > @@ -248,14 +247,6 @@ do_configure_prepend () {
> > > # so we copy it from the sysroot unistd.h to the perf unistd.h
> > > install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h
> > > ${S}/tools/include/uapi/asm-generic/unistd.h
> > > install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h
> > > ${S}/include/uapi/asm-generic/unistd.h
> > > -
> > > -# bits.h can have the same issue as unistd.h, so we make the tools
> > > variant take precedence
> > > -[ -e ${S}/tools/include/linux/bits.h ] && install -D -m0644
> > > ${S}/tools/include/linux/bits.h ${S}/include/linux/bits.h
> > > -
> > > -[ -e ${S}/tools/perf/util/include/linux/ctype.h ] && install -D
> > > -m0644 ${S}/include/linux/ctype.h
> > > ${S}/tools/perf/util/include/linux/ctype.h
> > > -
> > > -[ -e ${S}/include/uapi/linux/kvm.h ] && install -D -m0644
> > > ${S}/include/uapi/linux/kvm.h ${S}/tools/include/uapi/linux/kvm.h
> > > -[ -e ${S}/include/uapi/linux/sched.h ] && install -D -m0644
> > > ${S}/include/uapi/linux/sched.h ${S}/tools/include/uapi/linux/sched.h
> > > }
> > >
> > > python do_package_prepend() {
> > > --
> > > 2.19.1
> > >
> > > --
> > > ___
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> > --
> > Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Regards,
Andrey.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138703):
https://lists.openembedded.org/g/openembedded-core/message/138703
Mute This Topic: https://lists.openembedded.org/mt/72386349/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 6/6] perf: drop 'include' copy
On Mon, Oct 21, 2019 at 4:24 PM Martin Jansa wrote:
>
> On Mon, Oct 21, 2019 at 04:16:18PM -0400, bruce.ashfi...@gmail.com wrote:
> > From: Bruce Ashfield
> >
> > The copy of the kernel's top level include directory is not
> > required to build perf. We have both the linux-libc-headers and
> > perf's captured/copied headers for what it requires.
> >
> > The copy of the kernel's headers is leading us to multiple smaller
> > fixes to ensure that the various .h files are in sync. We can
> > remove the copy and all of the sync checks, and perf still builds
> > and executes correctly.
>
> Maybe reorder this before "[OE-core] [PATCH 3/6] perf: fix v5.4+ builds"
> as it removes most of what was possibly incorrectly added there (see 2nd
> review)
>
I left this here on purpose, since it is only RFC. The other patches
as they appear in the series are required to build against 5.4+, but
this is optional.
Bruce
> > Signed-off-by: Bruce Ashfield
> > ---
> > meta/recipes-kernel/perf/perf.bb | 9 -
> > 1 file changed, 9 deletions(-)
> >
> > diff --git a/meta/recipes-kernel/perf/perf.bb
> > b/meta/recipes-kernel/perf/perf.bb
> > index 191305969c..5f0ba7c180 100644
> > --- a/meta/recipes-kernel/perf/perf.bb
> > +++ b/meta/recipes-kernel/perf/perf.bb
> > @@ -106,7 +106,6 @@ EXTRA_OEMAKE += "\
> > EXTRA_OEMAKE_append_task-configure = " JOBS=1"
> >
> > PERF_SRC ?= "Makefile \
> > - include \
> > tools/arch \
> > tools/build \
> > tools/include \
> > @@ -248,14 +247,6 @@ do_configure_prepend () {
> > # so we copy it from the sysroot unistd.h to the perf unistd.h
> > install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h
> > ${S}/tools/include/uapi/asm-generic/unistd.h
> > install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h
> > ${S}/include/uapi/asm-generic/unistd.h
> > -
> > -# bits.h can have the same issue as unistd.h, so we make the tools
> > variant take precedence
> > -[ -e ${S}/tools/include/linux/bits.h ] && install -D -m0644
> > ${S}/tools/include/linux/bits.h ${S}/include/linux/bits.h
> > -
> > -[ -e ${S}/tools/perf/util/include/linux/ctype.h ] && install -D -m0644
> > ${S}/include/linux/ctype.h ${S}/tools/perf/util/include/linux/ctype.h
> > -
> > -[ -e ${S}/include/uapi/linux/kvm.h ] && install -D -m0644
> > ${S}/include/uapi/linux/kvm.h ${S}/tools/include/uapi/linux/kvm.h
> > -[ -e ${S}/include/uapi/linux/sched.h ] && install -D -m0644
> > ${S}/include/uapi/linux/sched.h ${S}/tools/include/uapi/linux/sched.h
> > }
> >
> > python do_package_prepend() {
> > --
> > 2.19.1
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 6/6] perf: drop 'include' copy
On Mon, Oct 21, 2019 at 04:16:18PM -0400, bruce.ashfi...@gmail.com wrote:
> From: Bruce Ashfield
>
> The copy of the kernel's top level include directory is not
> required to build perf. We have both the linux-libc-headers and
> perf's captured/copied headers for what it requires.
>
> The copy of the kernel's headers is leading us to multiple smaller
> fixes to ensure that the various .h files are in sync. We can
> remove the copy and all of the sync checks, and perf still builds
> and executes correctly.
Maybe reorder this before "[OE-core] [PATCH 3/6] perf: fix v5.4+ builds"
as it removes most of what was possibly incorrectly added there (see 2nd
review)
> Signed-off-by: Bruce Ashfield
> ---
> meta/recipes-kernel/perf/perf.bb | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/meta/recipes-kernel/perf/perf.bb
> b/meta/recipes-kernel/perf/perf.bb
> index 191305969c..5f0ba7c180 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -106,7 +106,6 @@ EXTRA_OEMAKE += "\
> EXTRA_OEMAKE_append_task-configure = " JOBS=1"
>
> PERF_SRC ?= "Makefile \
> - include \
> tools/arch \
> tools/build \
> tools/include \
> @@ -248,14 +247,6 @@ do_configure_prepend () {
> # so we copy it from the sysroot unistd.h to the perf unistd.h
> install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h
> ${S}/tools/include/uapi/asm-generic/unistd.h
> install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h
> ${S}/include/uapi/asm-generic/unistd.h
> -
> -# bits.h can have the same issue as unistd.h, so we make the tools
> variant take precedence
> -[ -e ${S}/tools/include/linux/bits.h ] && install -D -m0644
> ${S}/tools/include/linux/bits.h ${S}/include/linux/bits.h
> -
> -[ -e ${S}/tools/perf/util/include/linux/ctype.h ] && install -D -m0644
> ${S}/include/linux/ctype.h ${S}/tools/perf/util/include/linux/ctype.h
> -
> -[ -e ${S}/include/uapi/linux/kvm.h ] && install -D -m0644
> ${S}/include/uapi/linux/kvm.h ${S}/tools/include/uapi/linux/kvm.h
> -[ -e ${S}/include/uapi/linux/sched.h ] && install -D -m0644
> ${S}/include/uapi/linux/sched.h ${S}/tools/include/uapi/linux/sched.h
> }
>
> python do_package_prepend() {
> --
> 2.19.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/6] perf: drop 'include' copy
From: Bruce Ashfield
The copy of the kernel's top level include directory is not
required to build perf. We have both the linux-libc-headers and
perf's captured/copied headers for what it requires.
The copy of the kernel's headers is leading us to multiple smaller
fixes to ensure that the various .h files are in sync. We can
remove the copy and all of the sync checks, and perf still builds
and executes correctly.
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/perf/perf.bb | 9 -
1 file changed, 9 deletions(-)
diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 191305969c..5f0ba7c180 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -106,7 +106,6 @@ EXTRA_OEMAKE += "\
EXTRA_OEMAKE_append_task-configure = " JOBS=1"
PERF_SRC ?= "Makefile \
- include \
tools/arch \
tools/build \
tools/include \
@@ -248,14 +247,6 @@ do_configure_prepend () {
# so we copy it from the sysroot unistd.h to the perf unistd.h
install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h
${S}/tools/include/uapi/asm-generic/unistd.h
install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h
${S}/include/uapi/asm-generic/unistd.h
-
-# bits.h can have the same issue as unistd.h, so we make the tools variant
take precedence
-[ -e ${S}/tools/include/linux/bits.h ] && install -D -m0644
${S}/tools/include/linux/bits.h ${S}/include/linux/bits.h
-
-[ -e ${S}/tools/perf/util/include/linux/ctype.h ] && install -D -m0644
${S}/include/linux/ctype.h ${S}/tools/perf/util/include/linux/ctype.h
-
-[ -e ${S}/include/uapi/linux/kvm.h ] && install -D -m0644
${S}/include/uapi/linux/kvm.h ${S}/tools/include/uapi/linux/kvm.h
-[ -e ${S}/include/uapi/linux/sched.h ] && install -D -m0644
${S}/include/uapi/linux/sched.h ${S}/tools/include/uapi/linux/sched.h
}
python do_package_prepend() {
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
