kernel.bbclass: remove explicit version.h target
cover kernel.bbclass: remove explicit version.h target
Hi all,
I'm doing a quick RFC on a patch to get 3.7 based kernels building again.
The patch has the details on the kernel commits that have moved version.h around, which breaks our builds due to an explicit reference in kernel.bbclass.
I thought about making the call conditional, but as the patch says, this introduces a bit more complexity where it might not be required. Removing the reference to version.h fixes the build, and didn't break any of my older kernel builds (2.6.39, 3.0, 3.2, 3.4) while still producing version.h.
I can't locate the original reason that version.h was being directly built, so that's why this is a RFC. I'm hoping someone will yell if this breaks a use case that I don't know about.
This is stacked on top of my yocto master branch, since it was a RFC. I can rebase onto oe-core, or master under test as appropriate.
Cheers,
Bruce
The following changes since commit e6e2b9bd66100c078c029ca7e34829cf1dfb5490:
documentation: poky-ref-manual - edits to MACHINE type variables. (2012-10-18 12:15:04 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib zedd/kernel
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel
Bruce Ashfield (1):
kernel.bbclass: remove explicit version.h target
meta/classes/kernel.bbclass | 1 - 1 files changed, 0 insertions(+), 1 deletions(-)
Signature · 1 line
1.7.5.4
PATCH 1/1 kernel.bbclass: remove explicit version.h target
The compilation routine for the kernel has an explicit call to build version.h, which works fine for most kernels, but the location of it has recently changes.
commit d183e6f5 [UAPI: Move linux/version.h] commit 10b63956 [UAPI: Plumb the UAPI Kbuilds into the user
header installation and checking]
moves the file to include/generated/linux/version.h and then to include/generated/uapi/linux/version.h.
As a result kernel builds of 3.7 or bisection builds of intermediate kernel commits will fail with:
make[2]: *** No rule to make target `include/linux/version.h'. Stop.
Making the explicit version.h build conditional on the version, or via a file test would fix the problem, but it introduces some complexity to the build.
Even without an explicit call to build version.h, it is always produced by the kernel build, so it can simply be removed.
Note: it isn't clear why the explicit build of version.h was originally required, but the prep phases of the kernel have changed significantly, so it should no longer be required.
[YOCTO: #3293]
--- meta/classes/kernel.bbclass | 1 - 1 files changed, 0 insertions(+), 1 deletions(-)
meta/classes/kernel.bbclass +0 -1
@@ -85,7 +85,6 @@ KERNEL_IMAGETYPE_FOR_MAKE = "${@(lambda s: s[:-3] if s[-3:] == ".gz" else s)(d.g kernel_do_compile() { unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE - oe_runmake include/linux/version.h CC="${KERNEL_CC}" LD="${KERNEL_LD}" oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE} CC="${KERNEL_CC}" LD="${KERNEL_LD}" if test "${KERNEL_IMAGETYPE_FOR_MAKE}.gz" = "${KERNEL_IMAGETYPE}"; then gzip -9c < "${KERNEL_IMAGETYPE_FOR_MAKE}" > "${KERNEL_OUTPUT}"
Signature · 1 line
1.7.5.4
Quoted 20 lines · Bruce Ashfield
The compilation routine for the kernel has an explicit call to build
version.h, which works fine for most kernels, but the location of it has recently changes.commit
d183e6f5[UAPI: Movelinux/version.h] commit10b63956[UAPI: Plumb the UAPI Kbuilds into the user
header installation and checking]moves the file to
include/generated/linux/version.hand then toinclude/generated/uapi/linux/version.h.As a result kernel builds of 3.7 or bisection builds of intermediate kernel commits will fail with:
make[2]: *** No rule to make target `include/linux/version.h'. Stop.
Making the explicit
version.hbuild conditional on the version, or via a file test would fix the problem, but it introduces some complexity to the build.
Quoted 6 lines
Even without an explicit call to build
version.h, it is always produced by the kernel build, so it can simply be removed.Note: it isn't clear why the explicit build of
version.hwas originally required, but the prep phases of the kernel have changed significantly, so it should no longer be required.
How far back have you tested with? 3.0? If it works back to 3.0, then I'd argue it's just fine.
--
Darren
Quoted 21 lines
[YOCTO: #3293]
Signed-off-by Bruce Ashfield <[email protected]>--- meta/classes/kernel.bbclass | 1 - 1 files changed, 0 insertions(+), 1 deletions(-)meta/classes/kernel.bbclass +0
-1@@ -85,7 +85,6 @@ KERNEL_IMAGETYPE_FOR_MAKE = "${@(lambda s: s[:-3] if s[-3:] == ".gz" else s)(d.g kernel_do_compile() { unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE - oe_runmake include/linux/version.h CC="${KERNEL_CC}" LD="${KERNEL_LD}" oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE} CC="${KERNEL_CC}" LD="${KERNEL_LD}" if test "${KERNEL_IMAGETYPE_FOR_MAKE}.gz" = "${KERNEL_IMAGETYPE}"; then gzip -9c < "${KERNEL_IMAGETYPE_FOR_MAKE}" > "${KERNEL_OUTPUT}"
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel
Quoted 20 lines · Bruce Ashfield
The compilation routine for the kernel has an explicit call to build
version.h, which works fine for most kernels, but the location of it has recently changes.commit
d183e6f5[UAPI: Movelinux/version.h] commit10b63956[UAPI: Plumb the UAPI Kbuilds into the user
header installation and checking]moves the file to
include/generated/linux/version.hand then toinclude/generated/uapi/linux/version.h.As a result kernel builds of 3.7 or bisection builds of intermediate kernel commits will fail with:
make[2]: *** No rule to make target `include/linux/version.h'. Stop.
Making the explicit
version.hbuild conditional on the version, or via a file test would fix the problem, but it introduces some complexity to the build.
Quoted 6 lines
Even without an explicit call to build
version.h, it is always produced by the kernel build, so it can simply be removed.Note: it isn't clear why the explicit build of
version.hwas originally required, but the prep phases of the kernel have changed significantly, so it should no longer be required.
I had a look through the archives. I think this is a throwback to 2.4, we had to build the version.h file to figure out if we had a 2.6 or a 2.4 kernel, then we could do the right thing to build it.
Since we don't support 2.4 anymore, this can die!
Cheers,
Richard
Quoted 28 lines · Richard Purdie
Quoted 20 lines · Bruce Ashfield
The compilation routine for the kernel has an explicit call to build
version.h, which works fine for most kernels, but the location of it has recently changes.commit
d183e6f5[UAPI: Movelinux/version.h] commit10b63956[UAPI: Plumb the UAPI Kbuilds into the user
header installation and checking]moves the file to
include/generated/linux/version.hand then toinclude/generated/uapi/linux/version.h.As a result kernel builds of 3.7 or bisection builds of intermediate kernel commits will fail with:
make[2]: *** No rule to make target `include/linux/version.h'. Stop.
Making the explicit
version.hbuild conditional on the version, or via a file test would fix the problem, but it introduces some complexity to the build.Quoted 6 lines
Even without an explicit call to build
version.h, it is always produced by the kernel build, so it can simply be removed.Note: it isn't clear why the explicit build of
version.hwas originally required, but the prep phases of the kernel have changed significantly, so it should no longer be required.
Quoted 5 lines
I had a look through the archives. I think this is a throwback to 2.4, we had to build the
version.hfile to figure out if we had a 2.6 or a 2.4 kernel, then we could do the right thing to build it.Since we don't support 2.4 anymore, this can die!
That makes my day.
Should I resend, or is the RFC patch enough ?
Bruce
Quoted 5 lines
Cheers,
Richard
Quoted 33 lines · Bruce Ashfield
Quoted 32 lines · Richard Purdie
Quoted 20 lines · Bruce Ashfield
The compilation routine for the kernel has an explicit call to build
version.h, which works fine for most kernels, but the location of it has recently changes.commit
d183e6f5[UAPI: Movelinux/version.h] commit10b63956[UAPI: Plumb the UAPI Kbuilds into the user
header installation and checking]moves the file to
include/generated/linux/version.hand then toinclude/generated/uapi/linux/version.h.As a result kernel builds of 3.7 or bisection builds of intermediate kernel commits will fail with:
make[2]: *** No rule to make target `include/linux/version.h'. Stop.
Making the explicit
version.hbuild conditional on the version, or via a file test would fix the problem, but it introduces some complexity to the build.Quoted 6 lines
Even without an explicit call to build
version.h, it is always produced by the kernel build, so it can simply be removed.Note: it isn't clear why the explicit build of
version.hwas originally required, but the prep phases of the kernel have changed significantly, so it should no longer be required.I had a look through the archives. I think this is a throwback to 2.4, we had to build the
version.hfile to figure out if we had a 2.6 or a 2.4 kernel, then we could do the right thing to build it.
Quoted 6 lines
Quoted 1 line
Since we don't support 2.4 anymore, this can die!
That makes my day.
Should I resend, or is the RFC patch enough ?
Nope, It's merged into OE-Core
Thanks
Sau!
Quoted 15 lines
Bruce
Quoted 5 lines
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core