NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
9cedbcf494
kumquat-buildroot/package/linux-headers/linux-headers.mk

163 lines
6.7 KiB
Makefile
Raw Normal View History

kernel-headers: migrate to the package infrastructure [Peter: fix file header] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-06-30 21:28:58 +02:00
################################################################################
#
# linux-headers
#
################################################################################
# This package is used to provide Linux kernel headers for the
# internal toolchain backend.
linux-headers: prepare to support custom tarball/git This commit reworks how linux-headers.mk is written to prepare adding support for custom tarball/git fetching for the Linux kernel headers. Basically, the idea is to have a single condition at the beginning of the file that defines a number of LINUX_HADERS_* variables depending on whether "kernel headers same as kernel" is used or not, and then use these variables in the rest of the .mk file. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: split from the original patch "package/linux-headers: add support for custom headers" from Mark. The commit log is entirely mine.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:33:51 +02:00
# Set variables depending on whether we are using headers from a kernel
# build or a standalone header package.
package/linux-headers: add option to use same sources as the kernel Some heavily (and most often improperly) modified Linux kernels may export new APIs to userland, so as to speak to custom hardware or custom kernel facilities. However, we currently have no easy way to use such kernels as a source for the linux-headers package, which precludes having those userland headers intalled for userland applications to use them. We do have a way for the kernel to use the same version as for the headers, but that is definitely not enough, as the linux-headers package has a version choice that is far less versatile and capable than that of the linux package. Add a new option for the linux-headers package, for the user to specify that the version (really, the sources) of the kernel be used to install the headers from. We do that by making linux-headers patch-depend on the linux package. We can't have linux-header simply depend on linux, because the simple dependency means the the dependee will be configured, built and installed before the dependent is configured. And since linux is a target package, it depends on the toolchain, which internally dependes on linux-headers, which would depend on linux, and we'd get a circular dependency. Using patch-depend will ensure that linux is extracted and patched before linux-headers is extracted, which is really all we need. Then, we install the headers from the linux source tree, rather than from linux-headers' source tree (as there's nothing in there!). Since we need to install a private set for uClibc (see cde947f, uclibc: prevent rebuilding after installation to staging), we explicitly set INSTALL_HDR_PATH when calling the kernel' install-headers rule in LINUX_HEADERS_CONFIGURE_CMDS, so that the headers are installed in linux-headers' $(@D) instead of linux' $(@D). Finally, as there is no way to know the kernel version in this case, we must still prompt the user for the kernel series the headers are from (like we do for a custom version) and check for consistency at build time. Note however that this still leaves users that want to built their such-kernel outside of Buildroot out in the cold. [Peter: drop comment as suggested by Thomas] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Karoly Kasza <kaszak@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-20 19:34:28 +01:00
ifeq ($(BR2_KERNEL_HEADERS_AS_KERNEL),y)
linux-headers: prepare to support custom tarball/git This commit reworks how linux-headers.mk is written to prepare adding support for custom tarball/git fetching for the Linux kernel headers. Basically, the idea is to have a single condition at the beginning of the file that defines a number of LINUX_HADERS_* variables depending on whether "kernel headers same as kernel" is used or not, and then use these variables in the rest of the .mk file. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: split from the original patch "package/linux-headers: add support for custom headers" from Mark. The commit log is entirely mine.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:33:51 +02:00
LINUX_HEADERS_CUSTOM_TARBALL = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_TARBALL))
LINUX_HEADERS_CUSTOM_GIT = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_GIT))
LINUX_HEADERS_CUSTOM_HG = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_HG))
LINUX_HEADERS_CUSTOM_SVN = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_SVN))
linux-headers: fix circular dependency when HEADERS_AS_KERNEL is used The linux-headers -> linux dependency causes a circular dependency, breaking the source/legal-info/graph-depends/.. targets: make graph-depends Getting targets Getting dependencies for ['toolchain-buildroot', 'toolchain', 'busybox', 'glibc', 'initscripts', 'linux-headers', 'skeleton', 'linux', 'host-fakeroot', 'host-makedevs', 'rootfs-cpio', 'rootfs-initramfs'] Getting dependencies for ['host-kmod', 'host-gcc-final', 'host-gcc-initial', 'host-gawk'] Getting dependencies for ['host-gmp', 'host-binutils', 'host-pkgconf', 'host-mpfr', 'host-mpc'] Getting dependencies for ['host-m4'] Recursion detected for : toolchain which is a dependency of: linux which is a dependency of: linux-headers which is a dependency of: glibc which is a dependency of: host-gcc-final which is a dependency of: toolchain-buildroot which is a dependency of: toolchain Makefile:721: recipe for target 'graph-depends' failed make: *** [graph-depends] Error 1 Fix it by instead duplicating in linux-headers the 10-20 lines of linux.mk logic that infer the _SOURCE/_SITE/_VERSION from the BR2_LINUX_KERNEL_* variables. This does mean that we extract the kernel sources twice though. [Peter: use same git/hg tarball as linux kernel to not clone twice, minor fixes] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-02-24 15:04:09 +01:00
LINUX_HEADERS_VERSION = $(call qstrip,$(BR2_LINUX_KERNEL_VERSION))
linux-headers: prepare to support custom tarball/git This commit reworks how linux-headers.mk is written to prepare adding support for custom tarball/git fetching for the Linux kernel headers. Basically, the idea is to have a single condition at the beginning of the file that defines a number of LINUX_HADERS_* variables depending on whether "kernel headers same as kernel" is used or not, and then use these variables in the rest of the .mk file. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: split from the original patch "package/linux-headers: add support for custom headers" from Mark. The commit log is entirely mine.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:33:51 +02:00
LINUX_HEADERS_CUSTOM_TARBALL_LOCATION = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION))
LINUX_HEADERS_REPO_URL = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_URL))
package/linux-headers: add support for CIP kernel versions with same-as-kernel When the linux-headers are configured to use the same source as the kernel (BR2_KERNEL_HEADERS_AS_KERNEL), and the kernel is configured to be one of the two CIP versions (BR2_LINUX_KERNEL_LATEST_CIP_VERSION or BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION), the build fails if the kernel sources are not already downloaded: $ cat defconfig BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_LATEST_CIP_VERSION=y $ make defconfig BR2_DEFCONFIG=$pwd)/defconfig $ make linux-headers-source >>> linux-headers 4.19.118-cip25 Downloading --2020-05-13 19:28:44-- https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.118-cip25.tar.xz Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:1d::432, 151.101.121.176 Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:1d::432|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2020-05-13 19:28:45 ERROR 404: Not Found. make[1]: *** [package/pkg-generic.mk:171: /home/ymorin/dev/buildroot/O/build/linux-headers-4.19.118-cip25/.stamp_downloaded] Error 1 make: *** [Makefile:23: _all] Error 2 We fix that by adding yet another duplication of information out of the linux.mk, to use the CIP-specific git tree where to get the archives as snapshots. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-05-13 19:48:09 +02:00
LINUX_HEADERS_CIP = $(BR2_LINUX_KERNEL_LATEST_CIP_VERSION)$(BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION)
package/linux-headers: with headers from kernel, also override srcdir When using the headers from the kernel to be built, with the kernel set to a custom version, and overriding the kernel sources with LINUX_OVERRIDE_SRCDIR, the linux-headers package is still trying to download an archive, and fails to validate its hash. What is going on under the hood is that, with _OVERRIDE_SRCDIR, the _VERSION of a package is set to 'custom'. Furthermore, the variable BR_NO_CHECK_HASH_FOR is recursively expanded, so its value is only evaluated when it is needed. For linux-headers, we inherit the values from the linux package, and the LINUX_HEADERS_VERSION takes the value from the configuration. Thus we end up with the following situation: LINUX_VERSION=custom LINUX_HEADERS_VERSION=5.10 # For example BR_NO_CHECK_HASH_FOR=... linux-custom.tar.gz ... And thus the archive downloaded by linux-headers will not match any exclusion, and since there will most probably not be a hash for it, the download will fail, as was noticed and reported by Jarkko. But in this case, what we really want is to really use the headers from the kernel that we build, we do not even want to attempt a download at all. So, when using the headers from the kernel to be built, we also propagate the LINUX_OVERRIDE_SRCDIR to linux-headers, so that we also use the headers from the overridden sources. Furthermore, in that configuration, we explicitly disallow overriding the linux-headers specifically, as it does not make sense (even though, if they were overridden to the same location, that'd be OK, but to simplify the condition, we do not even check for that). Reported-by: Jarkko Sakkinen <jjs@kapsi.fi> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2021-01-27 22:24:13 +01:00
ifneq ($(LINUX_HEADERS_OVERRIDE_SRCDIR),)
$(error LINUX_HEADERS_OVERRIDE_SRCDIR must not be set when BR2_KERNEL_HEADERS_AS_KERNEL=y)
endif
LINUX_HEADERS_OVERRIDE_SRCDIR = $(LINUX_OVERRIDE_SRCDIR)
linux-headers: prepare to support custom tarball/git This commit reworks how linux-headers.mk is written to prepare adding support for custom tarball/git fetching for the Linux kernel headers. Basically, the idea is to have a single condition at the beginning of the file that defines a number of LINUX_HADERS_* variables depending on whether "kernel headers same as kernel" is used or not, and then use these variables in the rest of the .mk file. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: split from the original patch "package/linux-headers: add support for custom headers" from Mark. The commit log is entirely mine.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:33:51 +02:00
else # ! BR2_KERNEL_HEADERS_AS_KERNEL
package/linux-headers: add support for fetching from custom tarball/git Add support for building toolchains against custom headers. Allows the selection of a manual version, custom tarball or custom git repository for the kernel headers. This enables toolchains to be built against custom kernel headers without having to build a full kernel. This is particularly useful for new architectures, such as RISC-V where updated kernel headers may not have made it into the mainline kernel yet. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:43:12 +02:00
LINUX_HEADERS_CUSTOM_TARBALL = $(call qstrip,$(BR2_KERNEL_HEADERS_CUSTOM_TARBALL))
LINUX_HEADERS_CUSTOM_GIT = $(call qstrip,$(BR2_KERNEL_HEADERS_CUSTOM_GIT))
linux-headers: prepare to support custom tarball/git This commit reworks how linux-headers.mk is written to prepare adding support for custom tarball/git fetching for the Linux kernel headers. Basically, the idea is to have a single condition at the beginning of the file that defines a number of LINUX_HADERS_* variables depending on whether "kernel headers same as kernel" is used or not, and then use these variables in the rest of the .mk file. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: split from the original patch "package/linux-headers: add support for custom headers" from Mark. The commit log is entirely mine.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:33:51 +02:00
LINUX_HEADERS_CUSTOM_HG =
LINUX_HEADERS_CUSTOM_SVN =
LINUX_HEADERS_VERSION = $(call qstrip,$(BR2_DEFAULT_KERNEL_HEADERS))
package/linux-headers: add support for fetching from custom tarball/git Add support for building toolchains against custom headers. Allows the selection of a manual version, custom tarball or custom git repository for the kernel headers. This enables toolchains to be built against custom kernel headers without having to build a full kernel. This is particularly useful for new architectures, such as RISC-V where updated kernel headers may not have made it into the mainline kernel yet. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:43:12 +02:00
LINUX_HEADERS_CUSTOM_TARBALL_LOCATION = $(call qstrip,$(BR2_KERNEL_HEADERS_CUSTOM_TARBALL_LOCATION))
LINUX_HEADERS_REPO_URL = $(call qstrip,$(BR2_KERNEL_HEADERS_CUSTOM_REPO_URL))
package/linux-headers: add support for CIP kernel versions with same-as-kernel When the linux-headers are configured to use the same source as the kernel (BR2_KERNEL_HEADERS_AS_KERNEL), and the kernel is configured to be one of the two CIP versions (BR2_LINUX_KERNEL_LATEST_CIP_VERSION or BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION), the build fails if the kernel sources are not already downloaded: $ cat defconfig BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_LATEST_CIP_VERSION=y $ make defconfig BR2_DEFCONFIG=$pwd)/defconfig $ make linux-headers-source >>> linux-headers 4.19.118-cip25 Downloading --2020-05-13 19:28:44-- https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.118-cip25.tar.xz Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:1d::432, 151.101.121.176 Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:1d::432|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2020-05-13 19:28:45 ERROR 404: Not Found. make[1]: *** [package/pkg-generic.mk:171: /home/ymorin/dev/buildroot/O/build/linux-headers-4.19.118-cip25/.stamp_downloaded] Error 1 make: *** [Makefile:23: _all] Error 2 We fix that by adding yet another duplication of information out of the linux.mk, to use the CIP-specific git tree where to get the archives as snapshots. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-05-13 19:48:09 +02:00
LINUX_HEADERS_CIP =
linux-headers: prepare to support custom tarball/git This commit reworks how linux-headers.mk is written to prepare adding support for custom tarball/git fetching for the Linux kernel headers. Basically, the idea is to have a single condition at the beginning of the file that defines a number of LINUX_HADERS_* variables depending on whether "kernel headers same as kernel" is used or not, and then use these variables in the rest of the .mk file. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: split from the original patch "package/linux-headers: add support for custom headers" from Mark. The commit log is entirely mine.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:33:51 +02:00
endif # BR2_KERNEL_HEADERS_AS_KERNEL
package/linux-headers: fix support for -rc kernels -rc kernels after v3.x are no longer available in the testing subdirectory. Instead they should be fetched from cgit. Commit ff4cccbdcf5417a5a8c251ff302791a306023cc1 did this for linux itself, now we also do it for linux-headers. When fetched from cgit, .tar.xz can't be used. Adding this to the existing condition is not so simple, so refactor how _SOURCE is set: simply set it explicitly in each branch of the condition. While more verbose (it is repeated 4 times), it's easier to understand and to maintain. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-06 22:28:14 +01:00
# Compute LINUX_HEADERS_SOURCE and LINUX_HEADERS_SITE from the configuration
linux-headers: prepare to support custom tarball/git This commit reworks how linux-headers.mk is written to prepare adding support for custom tarball/git fetching for the Linux kernel headers. Basically, the idea is to have a single condition at the beginning of the file that defines a number of LINUX_HADERS_* variables depending on whether "kernel headers same as kernel" is used or not, and then use these variables in the rest of the .mk file. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: split from the original patch "package/linux-headers: add support for custom headers" from Mark. The commit log is entirely mine.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:33:51 +02:00
ifeq ($(LINUX_HEADERS_CUSTOM_TARBALL),y)
LINUX_HEADERS_SOURCE = $(notdir $(LINUX_HEADERS_CUSTOM_TARBALL_LOCATION))
LINUX_HEADERS_SITE = $(patsubst %/,%,$(dir $(LINUX_HEADERS_CUSTOM_TARBALL_LOCATION)))
else ifeq ($(LINUX_HEADERS_CUSTOM_GIT),y)
boot/barebox, package/linux-headers: carry site-method archive format version when overriding _SOURCE Commit 5b95a5dc2 (support/download: change format of archives generated from git) changed the way the archives generated from git repositories are named, adding a "format-version" identifier right between the package version and the file extension. Commit c043ecb20 (support/download: change format of archives generated from svn) did so for archives generated from a subversion checkout. However, for a few packages, we manually force the _SOURCE variable, because we want to share the archive with another package, to avoid downloading and storing those archives twice. This is the case for: - linux-headers and linux - barebox-aux and barebox When the generated tarballs were renamed with the aforementioned commits, those packages were not updated accordingly. Fix that by manually propagating the per-site-method format-version. Reported-by: "Stephane Viau (OSS)" <stephane.viau@oss.nxp.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: "Stephane Viau (OSS)" <stephane.viau@oss.nxp.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-01-18 19:16:12 +01:00
LINUX_HEADERS_SOURCE = linux-$(LINUX_HEADERS_VERSION)$(BR_FMT_VERSION_git).tar.gz
linux-headers: prepare to support custom tarball/git This commit reworks how linux-headers.mk is written to prepare adding support for custom tarball/git fetching for the Linux kernel headers. Basically, the idea is to have a single condition at the beginning of the file that defines a number of LINUX_HADERS_* variables depending on whether "kernel headers same as kernel" is used or not, and then use these variables in the rest of the .mk file. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: split from the original patch "package/linux-headers: add support for custom headers" from Mark. The commit log is entirely mine.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:33:51 +02:00
LINUX_HEADERS_SITE = $(LINUX_HEADERS_REPO_URL)
linux-headers: fix circular dependency when HEADERS_AS_KERNEL is used The linux-headers -> linux dependency causes a circular dependency, breaking the source/legal-info/graph-depends/.. targets: make graph-depends Getting targets Getting dependencies for ['toolchain-buildroot', 'toolchain', 'busybox', 'glibc', 'initscripts', 'linux-headers', 'skeleton', 'linux', 'host-fakeroot', 'host-makedevs', 'rootfs-cpio', 'rootfs-initramfs'] Getting dependencies for ['host-kmod', 'host-gcc-final', 'host-gcc-initial', 'host-gawk'] Getting dependencies for ['host-gmp', 'host-binutils', 'host-pkgconf', 'host-mpfr', 'host-mpc'] Getting dependencies for ['host-m4'] Recursion detected for : toolchain which is a dependency of: linux which is a dependency of: linux-headers which is a dependency of: glibc which is a dependency of: host-gcc-final which is a dependency of: toolchain-buildroot which is a dependency of: toolchain Makefile:721: recipe for target 'graph-depends' failed make: *** [graph-depends] Error 1 Fix it by instead duplicating in linux-headers the 10-20 lines of linux.mk logic that infer the _SOURCE/_SITE/_VERSION from the BR2_LINUX_KERNEL_* variables. This does mean that we extract the kernel sources twice though. [Peter: use same git/hg tarball as linux kernel to not clone twice, minor fixes] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-02-24 15:04:09 +01:00
LINUX_HEADERS_SITE_METHOD = git
linux-headers: prepare to support custom tarball/git This commit reworks how linux-headers.mk is written to prepare adding support for custom tarball/git fetching for the Linux kernel headers. Basically, the idea is to have a single condition at the beginning of the file that defines a number of LINUX_HADERS_* variables depending on whether "kernel headers same as kernel" is used or not, and then use these variables in the rest of the .mk file. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: split from the original patch "package/linux-headers: add support for custom headers" from Mark. The commit log is entirely mine.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:33:51 +02:00
else ifeq ($(LINUX_HEADERS_CUSTOM_HG),y)
package/linux-headers: fix support for -rc kernels -rc kernels after v3.x are no longer available in the testing subdirectory. Instead they should be fetched from cgit. Commit ff4cccbdcf5417a5a8c251ff302791a306023cc1 did this for linux itself, now we also do it for linux-headers. When fetched from cgit, .tar.xz can't be used. Adding this to the existing condition is not so simple, so refactor how _SOURCE is set: simply set it explicitly in each branch of the condition. While more verbose (it is repeated 4 times), it's easier to understand and to maintain. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-06 22:28:14 +01:00
LINUX_HEADERS_SOURCE = linux-$(LINUX_HEADERS_VERSION).tar.gz
linux-headers: prepare to support custom tarball/git This commit reworks how linux-headers.mk is written to prepare adding support for custom tarball/git fetching for the Linux kernel headers. Basically, the idea is to have a single condition at the beginning of the file that defines a number of LINUX_HADERS_* variables depending on whether "kernel headers same as kernel" is used or not, and then use these variables in the rest of the .mk file. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: split from the original patch "package/linux-headers: add support for custom headers" from Mark. The commit log is entirely mine.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:33:51 +02:00
LINUX_HEADERS_SITE = $(LINUX_HEADERS_REPO_URL)
linux-headers: fix circular dependency when HEADERS_AS_KERNEL is used The linux-headers -> linux dependency causes a circular dependency, breaking the source/legal-info/graph-depends/.. targets: make graph-depends Getting targets Getting dependencies for ['toolchain-buildroot', 'toolchain', 'busybox', 'glibc', 'initscripts', 'linux-headers', 'skeleton', 'linux', 'host-fakeroot', 'host-makedevs', 'rootfs-cpio', 'rootfs-initramfs'] Getting dependencies for ['host-kmod', 'host-gcc-final', 'host-gcc-initial', 'host-gawk'] Getting dependencies for ['host-gmp', 'host-binutils', 'host-pkgconf', 'host-mpfr', 'host-mpc'] Getting dependencies for ['host-m4'] Recursion detected for : toolchain which is a dependency of: linux which is a dependency of: linux-headers which is a dependency of: glibc which is a dependency of: host-gcc-final which is a dependency of: toolchain-buildroot which is a dependency of: toolchain Makefile:721: recipe for target 'graph-depends' failed make: *** [graph-depends] Error 1 Fix it by instead duplicating in linux-headers the 10-20 lines of linux.mk logic that infer the _SOURCE/_SITE/_VERSION from the BR2_LINUX_KERNEL_* variables. This does mean that we extract the kernel sources twice though. [Peter: use same git/hg tarball as linux kernel to not clone twice, minor fixes] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-02-24 15:04:09 +01:00
LINUX_HEADERS_SITE_METHOD = hg
linux-headers: prepare to support custom tarball/git This commit reworks how linux-headers.mk is written to prepare adding support for custom tarball/git fetching for the Linux kernel headers. Basically, the idea is to have a single condition at the beginning of the file that defines a number of LINUX_HADERS_* variables depending on whether "kernel headers same as kernel" is used or not, and then use these variables in the rest of the .mk file. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: split from the original patch "package/linux-headers: add support for custom headers" from Mark. The commit log is entirely mine.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:33:51 +02:00
else ifeq ($(LINUX_HEADERS_CUSTOM_SVN),y)
boot/barebox, package/linux-headers: carry site-method archive format version when overriding _SOURCE Commit 5b95a5dc2 (support/download: change format of archives generated from git) changed the way the archives generated from git repositories are named, adding a "format-version" identifier right between the package version and the file extension. Commit c043ecb20 (support/download: change format of archives generated from svn) did so for archives generated from a subversion checkout. However, for a few packages, we manually force the _SOURCE variable, because we want to share the archive with another package, to avoid downloading and storing those archives twice. This is the case for: - linux-headers and linux - barebox-aux and barebox When the generated tarballs were renamed with the aforementioned commits, those packages were not updated accordingly. Fix that by manually propagating the per-site-method format-version. Reported-by: "Stephane Viau (OSS)" <stephane.viau@oss.nxp.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: "Stephane Viau (OSS)" <stephane.viau@oss.nxp.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-01-18 19:16:12 +01:00
LINUX_HEADERS_SOURCE = linux-$(LINUX_HEADERS_VERSION)$(BR_FMT_VERSION_svn).tar.gz
linux-headers: prepare to support custom tarball/git This commit reworks how linux-headers.mk is written to prepare adding support for custom tarball/git fetching for the Linux kernel headers. Basically, the idea is to have a single condition at the beginning of the file that defines a number of LINUX_HADERS_* variables depending on whether "kernel headers same as kernel" is used or not, and then use these variables in the rest of the .mk file. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: split from the original patch "package/linux-headers: add support for custom headers" from Mark. The commit log is entirely mine.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:33:51 +02:00
LINUX_HEADERS_SITE = $(LINUX_HEADERS_REPO_URL)
LINUX_HEADERS_SITE_METHOD = svn
package/linux-headers: add support for CIP kernel versions with same-as-kernel When the linux-headers are configured to use the same source as the kernel (BR2_KERNEL_HEADERS_AS_KERNEL), and the kernel is configured to be one of the two CIP versions (BR2_LINUX_KERNEL_LATEST_CIP_VERSION or BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION), the build fails if the kernel sources are not already downloaded: $ cat defconfig BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_LATEST_CIP_VERSION=y $ make defconfig BR2_DEFCONFIG=$pwd)/defconfig $ make linux-headers-source >>> linux-headers 4.19.118-cip25 Downloading --2020-05-13 19:28:44-- https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.118-cip25.tar.xz Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:1d::432, 151.101.121.176 Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:1d::432|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2020-05-13 19:28:45 ERROR 404: Not Found. make[1]: *** [package/pkg-generic.mk:171: /home/ymorin/dev/buildroot/O/build/linux-headers-4.19.118-cip25/.stamp_downloaded] Error 1 make: *** [Makefile:23: _all] Error 2 We fix that by adding yet another duplication of information out of the linux.mk, to use the CIP-specific git tree where to get the archives as snapshots. Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-05-13 19:48:09 +02:00
else ifeq ($(LINUX_HEADERS_CIP),y)
LINUX_HEADERS_SOURCE = linux-cip-$(LINUX_HEADERS_VERSION).tar.gz
LINUX_HEADERS_SITE = https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/snapshot
package/linux-headers: fix support for -rc kernels -rc kernels after v3.x are no longer available in the testing subdirectory. Instead they should be fetched from cgit. Commit ff4cccbdcf5417a5a8c251ff302791a306023cc1 did this for linux itself, now we also do it for linux-headers. When fetched from cgit, .tar.xz can't be used. Adding this to the existing condition is not so simple, so refactor how _SOURCE is set: simply set it explicitly in each branch of the condition. While more verbose (it is repeated 4 times), it's easier to understand and to maintain. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-06 22:28:14 +01:00
else ifneq ($(findstring -rc,$(LINUX_HEADERS_VERSION)),)
# Since 4.12-rc1, -rc kernels are generated from cgit. This also works for
# older -rc kernels.
LINUX_HEADERS_SOURCE = linux-$(LINUX_HEADERS_VERSION).tar.gz
LINUX_HEADERS_SITE = https://git.kernel.org/torvalds/t
linux-headers: fix circular dependency when HEADERS_AS_KERNEL is used The linux-headers -> linux dependency causes a circular dependency, breaking the source/legal-info/graph-depends/.. targets: make graph-depends Getting targets Getting dependencies for ['toolchain-buildroot', 'toolchain', 'busybox', 'glibc', 'initscripts', 'linux-headers', 'skeleton', 'linux', 'host-fakeroot', 'host-makedevs', 'rootfs-cpio', 'rootfs-initramfs'] Getting dependencies for ['host-kmod', 'host-gcc-final', 'host-gcc-initial', 'host-gawk'] Getting dependencies for ['host-gmp', 'host-binutils', 'host-pkgconf', 'host-mpfr', 'host-mpc'] Getting dependencies for ['host-m4'] Recursion detected for : toolchain which is a dependency of: linux which is a dependency of: linux-headers which is a dependency of: glibc which is a dependency of: host-gcc-final which is a dependency of: toolchain-buildroot which is a dependency of: toolchain Makefile:721: recipe for target 'graph-depends' failed make: *** [graph-depends] Error 1 Fix it by instead duplicating in linux-headers the 10-20 lines of linux.mk logic that infer the _SOURCE/_SITE/_VERSION from the BR2_LINUX_KERNEL_* variables. This does mean that we extract the kernel sources twice though. [Peter: use same git/hg tarball as linux kernel to not clone twice, minor fixes] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-02-24 15:04:09 +01:00
else
package/linux-headers: fix support for -rc kernels -rc kernels after v3.x are no longer available in the testing subdirectory. Instead they should be fetched from cgit. Commit ff4cccbdcf5417a5a8c251ff302791a306023cc1 did this for linux itself, now we also do it for linux-headers. When fetched from cgit, .tar.xz can't be used. Adding this to the existing condition is not so simple, so refactor how _SOURCE is set: simply set it explicitly in each branch of the condition. While more verbose (it is repeated 4 times), it's easier to understand and to maintain. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-06 22:28:14 +01:00
LINUX_HEADERS_SOURCE = linux-$(LINUX_HEADERS_VERSION).tar.xz
linux-headers: fix circular dependency when HEADERS_AS_KERNEL is used The linux-headers -> linux dependency causes a circular dependency, breaking the source/legal-info/graph-depends/.. targets: make graph-depends Getting targets Getting dependencies for ['toolchain-buildroot', 'toolchain', 'busybox', 'glibc', 'initscripts', 'linux-headers', 'skeleton', 'linux', 'host-fakeroot', 'host-makedevs', 'rootfs-cpio', 'rootfs-initramfs'] Getting dependencies for ['host-kmod', 'host-gcc-final', 'host-gcc-initial', 'host-gawk'] Getting dependencies for ['host-gmp', 'host-binutils', 'host-pkgconf', 'host-mpfr', 'host-mpc'] Getting dependencies for ['host-m4'] Recursion detected for : toolchain which is a dependency of: linux which is a dependency of: linux-headers which is a dependency of: glibc which is a dependency of: host-gcc-final which is a dependency of: toolchain-buildroot which is a dependency of: toolchain Makefile:721: recipe for target 'graph-depends' failed make: *** [graph-depends] Error 1 Fix it by instead duplicating in linux-headers the 10-20 lines of linux.mk logic that infer the _SOURCE/_SITE/_VERSION from the BR2_LINUX_KERNEL_* variables. This does mean that we extract the kernel sources twice though. [Peter: use same git/hg tarball as linux kernel to not clone twice, minor fixes] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-02-24 15:04:09 +01:00
ifeq ($(findstring x2.6.,x$(LINUX_HEADERS_VERSION)),x2.6.)
LINUX_HEADERS_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v2.6
linux{, -headers}: support downloads of v5+ With the arrival of linux v5.0, we need yet another condition to set _SITE correctly. Instead of continuing this madness, solve the problem generically: use v2.6 for 2.6.*, and use the number before the first dot in the other cases. While we're at it, remove the comment which has been incorrect since 80d7b68167a5c8893e906ace6b5f0b0166336406 (7 years ago). Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Tested-by: Jan Kundrát <jan.kundrat@cesnet.cz> Tested-by: Adam Duskett <aduskett@gmail.com> Reviewed-by: Adam Duskett <aduskett@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-06 22:28:15 +01:00
else
LINUX_HEADERS_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v$(firstword $(subst ., ,$(LINUX_HEADERS_VERSION))).x
linux-headers: prepare to support custom tarball/git This commit reworks how linux-headers.mk is written to prepare adding support for custom tarball/git fetching for the Linux kernel headers. Basically, the idea is to have a single condition at the beginning of the file that defines a number of LINUX_HADERS_* variables depending on whether "kernel headers same as kernel" is used or not, and then use these variables in the rest of the .mk file. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: split from the original patch "package/linux-headers: add support for custom headers" from Mark. The commit log is entirely mine.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:33:51 +02:00
endif # x2.6
endif # LINUX_HEADERS_CUSTOM_TARBALL
package/linux-headers: add option to use same sources as the kernel Some heavily (and most often improperly) modified Linux kernels may export new APIs to userland, so as to speak to custom hardware or custom kernel facilities. However, we currently have no easy way to use such kernels as a source for the linux-headers package, which precludes having those userland headers intalled for userland applications to use them. We do have a way for the kernel to use the same version as for the headers, but that is definitely not enough, as the linux-headers package has a version choice that is far less versatile and capable than that of the linux package. Add a new option for the linux-headers package, for the user to specify that the version (really, the sources) of the kernel be used to install the headers from. We do that by making linux-headers patch-depend on the linux package. We can't have linux-header simply depend on linux, because the simple dependency means the the dependee will be configured, built and installed before the dependent is configured. And since linux is a target package, it depends on the toolchain, which internally dependes on linux-headers, which would depend on linux, and we'd get a circular dependency. Using patch-depend will ensure that linux is extracted and patched before linux-headers is extracted, which is really all we need. Then, we install the headers from the linux source tree, rather than from linux-headers' source tree (as there's nothing in there!). Since we need to install a private set for uClibc (see cde947f, uclibc: prevent rebuilding after installation to staging), we explicitly set INSTALL_HDR_PATH when calling the kernel' install-headers rule in LINUX_HEADERS_CONFIGURE_CMDS, so that the headers are installed in linux-headers' $(@D) instead of linux' $(@D). Finally, as there is no way to know the kernel version in this case, we must still prompt the user for the kernel series the headers are from (like we do for a custom version) and check for consistency at build time. Note however that this still leaves users that want to built their such-kernel outside of Buildroot out in the cold. [Peter: drop comment as suggested by Thomas] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Karoly Kasza <kaszak@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-20 19:34:28 +01:00
linux-headers: prepare to support custom tarball/git This commit reworks how linux-headers.mk is written to prepare adding support for custom tarball/git fetching for the Linux kernel headers. Basically, the idea is to have a single condition at the beginning of the file that defines a number of LINUX_HADERS_* variables depending on whether "kernel headers same as kernel" is used or not, and then use these variables in the rest of the .mk file. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: split from the original patch "package/linux-headers: add support for custom headers" from Mark. The commit log is entirely mine.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:33:51 +02:00
# Apply any necessary patches if we are using the headers from a kernel
# build.
ifeq ($(BR2_KERNEL_HEADERS_AS_KERNEL),y)
package/linux-headers: apply all Linux patches when BR2_KERNEL_HEADERS_AS_KERNEL=y When BR2_KERNEL_HEADERS_AS_KERNEL=y, we expect that the Linux kernel headers code will be exactly the same as the Linux kernel code itself. The code currently takes into account the patches defined by BR2_LINUX_KERNEL_PATCH, but not the kernel patches that are stored in linux's BR2_GLOBAL_PATCH_DIR. So for example, the current qemu_riscv32_virt_defconfig has: BR2_GLOBAL_PATCH_DIR="board/qemu/riscv32-virt/patches/" With: board/qemu/riscv32-virt/patches/ └── linux └── 0001-Revert-riscv-Use-latest-system-call-ABI.patch This patch gets properly applied when the Linux kernel is built, but not when the linux-headers package is built. This commit fixes that by making sure patches stored in the "linux" BR2_GLOBAL_PATCH_DIR subdirectory are taken into account. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Acked-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-08-04 11:36:44 +02:00
LINUX_HEADERS_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH)) \
$(wildcard $(addsuffix /linux,$(call qstrip,$(BR2_GLOBAL_PATCH_DIR))))
linux-headers: fix circular dependency when HEADERS_AS_KERNEL is used The linux-headers -> linux dependency causes a circular dependency, breaking the source/legal-info/graph-depends/.. targets: make graph-depends Getting targets Getting dependencies for ['toolchain-buildroot', 'toolchain', 'busybox', 'glibc', 'initscripts', 'linux-headers', 'skeleton', 'linux', 'host-fakeroot', 'host-makedevs', 'rootfs-cpio', 'rootfs-initramfs'] Getting dependencies for ['host-kmod', 'host-gcc-final', 'host-gcc-initial', 'host-gawk'] Getting dependencies for ['host-gmp', 'host-binutils', 'host-pkgconf', 'host-mpfr', 'host-mpc'] Getting dependencies for ['host-m4'] Recursion detected for : toolchain which is a dependency of: linux which is a dependency of: linux-headers which is a dependency of: glibc which is a dependency of: host-gcc-final which is a dependency of: toolchain-buildroot which is a dependency of: toolchain Makefile:721: recipe for target 'graph-depends' failed make: *** [graph-depends] Error 1 Fix it by instead duplicating in linux-headers the 10-20 lines of linux.mk logic that infer the _SOURCE/_SITE/_VERSION from the BR2_LINUX_KERNEL_* variables. This does mean that we extract the kernel sources twice though. [Peter: use same git/hg tarball as linux kernel to not clone twice, minor fixes] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-02-24 15:04:09 +01:00
# We rely on the generic package infrastructure to download and apply
# remote patches (downloaded from ftp, http or https). For local
# patches, we can't rely on that infrastructure, because there might
# be directories in the patch list (unlike for other packages).
LINUX_HEADERS_PATCH = $(filter ftp://% http://% https://%,$(LINUX_HEADERS_PATCHES))
define LINUX_HEADERS_APPLY_LOCAL_PATCHES
for p in $(filter-out ftp://% http://% https://%,$(LINUX_HEADERS_PATCHES)) ; do \
if test -d $$p ; then \
$(APPLY_PATCHES) $(@D) $$p \*.patch || exit 1 ; \
else \
$(APPLY_PATCHES) $(@D) `dirname $$p` `basename $$p` || exit 1; \
fi \
done
endef
package/linux-headers: add option to use same sources as the kernel Some heavily (and most often improperly) modified Linux kernels may export new APIs to userland, so as to speak to custom hardware or custom kernel facilities. However, we currently have no easy way to use such kernels as a source for the linux-headers package, which precludes having those userland headers intalled for userland applications to use them. We do have a way for the kernel to use the same version as for the headers, but that is definitely not enough, as the linux-headers package has a version choice that is far less versatile and capable than that of the linux package. Add a new option for the linux-headers package, for the user to specify that the version (really, the sources) of the kernel be used to install the headers from. We do that by making linux-headers patch-depend on the linux package. We can't have linux-header simply depend on linux, because the simple dependency means the the dependee will be configured, built and installed before the dependent is configured. And since linux is a target package, it depends on the toolchain, which internally dependes on linux-headers, which would depend on linux, and we'd get a circular dependency. Using patch-depend will ensure that linux is extracted and patched before linux-headers is extracted, which is really all we need. Then, we install the headers from the linux source tree, rather than from linux-headers' source tree (as there's nothing in there!). Since we need to install a private set for uClibc (see cde947f, uclibc: prevent rebuilding after installation to staging), we explicitly set INSTALL_HDR_PATH when calling the kernel' install-headers rule in LINUX_HEADERS_CONFIGURE_CMDS, so that the headers are installed in linux-headers' $(@D) instead of linux' $(@D). Finally, as there is no way to know the kernel version in this case, we must still prompt the user for the kernel series the headers are from (like we do for a custom version) and check for consistency at build time. Note however that this still leaves users that want to built their such-kernel outside of Buildroot out in the cold. [Peter: drop comment as suggested by Thomas] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Karoly Kasza <kaszak@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-20 19:34:28 +01:00
linux-headers: fix circular dependency when HEADERS_AS_KERNEL is used The linux-headers -> linux dependency causes a circular dependency, breaking the source/legal-info/graph-depends/.. targets: make graph-depends Getting targets Getting dependencies for ['toolchain-buildroot', 'toolchain', 'busybox', 'glibc', 'initscripts', 'linux-headers', 'skeleton', 'linux', 'host-fakeroot', 'host-makedevs', 'rootfs-cpio', 'rootfs-initramfs'] Getting dependencies for ['host-kmod', 'host-gcc-final', 'host-gcc-initial', 'host-gawk'] Getting dependencies for ['host-gmp', 'host-binutils', 'host-pkgconf', 'host-mpfr', 'host-mpc'] Getting dependencies for ['host-m4'] Recursion detected for : toolchain which is a dependency of: linux which is a dependency of: linux-headers which is a dependency of: glibc which is a dependency of: host-gcc-final which is a dependency of: toolchain-buildroot which is a dependency of: toolchain Makefile:721: recipe for target 'graph-depends' failed make: *** [graph-depends] Error 1 Fix it by instead duplicating in linux-headers the 10-20 lines of linux.mk logic that infer the _SOURCE/_SITE/_VERSION from the BR2_LINUX_KERNEL_* variables. This does mean that we extract the kernel sources twice though. [Peter: use same git/hg tarball as linux kernel to not clone twice, minor fixes] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-02-24 15:04:09 +01:00
LINUX_HEADERS_POST_PATCH_HOOKS += LINUX_HEADERS_APPLY_LOCAL_PATCHES
linux-headers: prepare to support custom tarball/git This commit reworks how linux-headers.mk is written to prepare adding support for custom tarball/git fetching for the Linux kernel headers. Basically, the idea is to have a single condition at the beginning of the file that defines a number of LINUX_HADERS_* variables depending on whether "kernel headers same as kernel" is used or not, and then use these variables in the rest of the .mk file. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: split from the original patch "package/linux-headers: add support for custom headers" from Mark. The commit log is entirely mine.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:33:51 +02:00
endif # BR2_KERNEL_HEADERS_AS_KERNEL
package/linux-headers: add option to use same sources as the kernel Some heavily (and most often improperly) modified Linux kernels may export new APIs to userland, so as to speak to custom hardware or custom kernel facilities. However, we currently have no easy way to use such kernels as a source for the linux-headers package, which precludes having those userland headers intalled for userland applications to use them. We do have a way for the kernel to use the same version as for the headers, but that is definitely not enough, as the linux-headers package has a version choice that is far less versatile and capable than that of the linux package. Add a new option for the linux-headers package, for the user to specify that the version (really, the sources) of the kernel be used to install the headers from. We do that by making linux-headers patch-depend on the linux package. We can't have linux-header simply depend on linux, because the simple dependency means the the dependee will be configured, built and installed before the dependent is configured. And since linux is a target package, it depends on the toolchain, which internally dependes on linux-headers, which would depend on linux, and we'd get a circular dependency. Using patch-depend will ensure that linux is extracted and patched before linux-headers is extracted, which is really all we need. Then, we install the headers from the linux source tree, rather than from linux-headers' source tree (as there's nothing in there!). Since we need to install a private set for uClibc (see cde947f, uclibc: prevent rebuilding after installation to staging), we explicitly set INSTALL_HDR_PATH when calling the kernel' install-headers rule in LINUX_HEADERS_CONFIGURE_CMDS, so that the headers are installed in linux-headers' $(@D) instead of linux' $(@D). Finally, as there is no way to know the kernel version in this case, we must still prompt the user for the kernel series the headers are from (like we do for a custom version) and check for consistency at build time. Note however that this still leaves users that want to built their such-kernel outside of Buildroot out in the cold. [Peter: drop comment as suggested by Thomas] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Karoly Kasza <kaszak@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-20 19:34:28 +01:00
linux-headers: prepare to support custom tarball/git This commit reworks how linux-headers.mk is written to prepare adding support for custom tarball/git fetching for the Linux kernel headers. Basically, the idea is to have a single condition at the beginning of the file that defines a number of LINUX_HADERS_* variables depending on whether "kernel headers same as kernel" is used or not, and then use these variables in the rest of the .mk file. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: split from the original patch "package/linux-headers: add support for custom headers" from Mark. The commit log is entirely mine.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:33:51 +02:00
# Skip hash checking for custom kernel headers.
package/linux-headers: add support for fetching from custom tarball/git Add support for building toolchains against custom headers. Allows the selection of a manual version, custom tarball or custom git repository for the kernel headers. This enables toolchains to be built against custom kernel headers without having to build a full kernel. This is particularly useful for new architectures, such as RISC-V where updated kernel headers may not have made it into the mainline kernel yet. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:43:12 +02:00
ifeq ($(BR2_KERNEL_HEADERS_VERSION)$(BR2_KERNEL_HEADERS_CUSTOM_TARBALL)$(BR2_KERNEL_HEADERS_CUSTOM_GIT),y)
linux-headers: rework hash exclusion Although we currently don't have a .hash file for linux-headers, there already are exclusions for the BR2_KERNEL_HEADERS_AS_KERNEL case (copied from linux.mk). However, there is no exclusion for the BR2_KERNEL_HEADERS_VERSION case. For the BR2_KERNEL_HEADERS_AS_KERNEL case, the exclusion is actually not needed. Indeed, KERNEL_HEADERS_SOURCE is computed to be the same value as LINUX_SOURCE, and linux.mk already adds LINUX_SOURCE to BR_NO_CHECK_HASH_FOR. For the other cases, we should exclude the BR2_KERNEL_HEADERS_VERSION case because there the user supplies the version so it can't be included in the .hash file. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-21 01:07:06 +01:00
BR_NO_CHECK_HASH_FOR += $(LINUX_HEADERS_SOURCE)
endif
package: share downloaded files for big packages Theses packages are given as an example of the use of the *_DL_SUBDIR feature. There maybe other packages that would benefit from that feature, they would need to be added on a case by case basis. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-04-02 16:57:58 +02:00
# linux-headers really is the same as the linux package
LINUX_HEADERS_DL_SUBDIR = linux
boot, linux, package: use SPDX short identifier for GPLv2/GPLv2+ We want to use SPDX identifier for license strings as much as possible. SPDX short identifier for GPLv2/GPLv2+ is GPL-2.0/GPL-2.0+. This change is done by using following command. find . -name "*.mk" | xargs sed -ri '/LICENSE( )?[\+:]?=/s/\<GPLv2\>/GPL-2.0/g' Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-30 15:43:32 +02:00
LINUX_HEADERS_LICENSE = GPL-2.0
package/linux-headers: license files hashes only valid for latest version Like we did for the linux kernel, change linux-headers to only check the license hashes for the latest known version as the content of COPYING has changed between versions. To simplify the test, we introduce an intermediate, blind option that get selected when the latest kernel sources are used. Reported-by: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Markus Mayer <mmayer@broadcom.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-02-05 15:48:39 +01:00
ifeq ($(BR2_KERNEL_HEADERS_LATEST),y)
LINUX_HEADERS_LICENSE_FILES = \
COPYING \
LICENSES/preferred/GPL-2.0 \
LICENSES/exceptions/Linux-syscall-note
endif
package: provide CPE ID details for numerous packages This patch adds CPE ID information for a significant number of packages. Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-12-04 16:46:01 +01:00
LINUX_HEADERS_CPE_ID_VENDOR = linux
Replace LIBFOO_CPE_ID_NAME by LIBFOO_CPE_ID_PRODUCT Replace LIBFOO_CPE_ID_NAME by LIBFOO_CPE_ID_PRODUCT to better "comply" with the official "Well-Formed CPE Name Data Model" parameters: - https://csrc.nist.gov/publications/detail/nistir/7695/final - https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-01-18 18:41:51 +01:00
LINUX_HEADERS_CPE_ID_PRODUCT = linux_kernel
kernel-headers: migrate to the package infrastructure [Peter: fix file header] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-06-30 21:28:58 +02:00
LINUX_HEADERS_INSTALL_STAGING = YES
package: add toolchain dependency to every target package This commit makes the dependency from the target toolchain explicit. This way we can buid from command line a package that use inner-generic-package right after the configuration phase, example: make clean <package-name> Also remove TARGETS_ALL because the only purpose was to add toolchain dependency so it's superseded by this commit. To prevent circular dependency add the new variable <pkgname>_ADD_TOOLCHAIN_DEPENDENCY to avoid adding the toolchain dependency for toolchain packages. This is also a step forward supporting top-level parallel make. Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-02-14 10:55:04 +01:00
# linux-headers is part of the toolchain so disable the toolchain dependency
LINUX_HEADERS_ADD_TOOLCHAIN_DEPENDENCY = NO
package/linux-headers: add comment to safely ignore missing cross-compiler For some architectures (eg. Arc, Cris, Hexagon, ia64, Parisc, Score and Xtensa), the Linux buildsystem tries to call the cross-compiler when installing the headers. This is a spurious call, since a cross-compiler is not needed at all to install the headers. As some users have reported the issue, just add a comment in linux-headers.mk directing the user to ignore those errors. Reported-by: Noam Camus <noamc@ezchip.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-02-23 15:35:18 +01:00
# For some architectures (eg. Arc, Cris, Hexagon, ia64, parisc,
# score and xtensa), the Linux buildsystem tries to call the
# cross-compiler, although it is not needed at all.
# This results in seemingly errors like:
# [...]/scripts/gcc-version.sh: line 26: arc-linux-uclibc-gcc: command not found
# Those can be safely ignored.
uclibc: prevent rebuilding after installation to staging Currently we configure uClibc to use kernel headers from "staging" folder with KERNEL_HEADERS="$(STAGING_DIR)/usr/include". This path is added to include search path of uClibc build system in Rules.mak "CFLAGS += -I$(KERNEL_HEADERS)". At the same time on uClibc installation to "staging" we point to the same location "$(STAGING_DIR)/usr" (headers effectively go in "usr/include"). So after every installation to "staging" dependences get touched (even though we copy the same headers every time) and so we may see lots of sources in uClibc get rebuilt. This has 2 consequences: 1. Longer build time - becase even on ordinary buildroot build uClibc is built twice. On "uclibc building" and on "uclibc installation to target". 2. Symbols in libuClibc built initially (that is later installed in "staging/sysroot") are situated with different offset compared to second build (later copied in "target"). This happens because as described above only part of sources get rebuilt and then on final linkage object files are linked in different order. And (2) leads to problems on remote rebugging: gdbserver reports offsets that correspond to pointless assembly in libuClibc on host. Here's how it looks like. Before this patch: $ cd ~/br2_output/i586/target/lib $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill 423: 0000c42c 54 FUNC GLOBAL DEFAULT 7 kill $ cd ~/br2_output/i586/staging/lib $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill 423: 0000b518 54 FUNC GLOBAL DEFAULT 7 kill After this patch: $ cd ~/br2_output/i586/target/lib $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill 423: 0000b518 54 FUNC GLOBAL DEFAULT 7 kill $ cd ~/br2_output/i586/staging/lib $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill 423: 0000b518 54 FUNC GLOBAL DEFAULT 7 kill Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Noam Camus <noamc@ezchip.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-06-04 22:27:33 +02:00
# This step is required to have a separate linux headers location for
# uClibc building. This way uClibc doesn't modify linux headers on installation
# of "its" headers
define LINUX_HEADERS_CONFIGURE_CMDS
linux-headers: fix circular dependency when HEADERS_AS_KERNEL is used The linux-headers -> linux dependency causes a circular dependency, breaking the source/legal-info/graph-depends/.. targets: make graph-depends Getting targets Getting dependencies for ['toolchain-buildroot', 'toolchain', 'busybox', 'glibc', 'initscripts', 'linux-headers', 'skeleton', 'linux', 'host-fakeroot', 'host-makedevs', 'rootfs-cpio', 'rootfs-initramfs'] Getting dependencies for ['host-kmod', 'host-gcc-final', 'host-gcc-initial', 'host-gawk'] Getting dependencies for ['host-gmp', 'host-binutils', 'host-pkgconf', 'host-mpfr', 'host-mpc'] Getting dependencies for ['host-m4'] Recursion detected for : toolchain which is a dependency of: linux which is a dependency of: linux-headers which is a dependency of: glibc which is a dependency of: host-gcc-final which is a dependency of: toolchain-buildroot which is a dependency of: toolchain Makefile:721: recipe for target 'graph-depends' failed make: *** [graph-depends] Error 1 Fix it by instead duplicating in linux-headers the 10-20 lines of linux.mk logic that infer the _SOURCE/_SITE/_VERSION from the BR2_LINUX_KERNEL_* variables. This does mean that we extract the kernel sources twice though. [Peter: use same git/hg tarball as linux kernel to not clone twice, minor fixes] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-02-24 15:04:09 +01:00
(cd $(@D); \
uclibc: prevent rebuilding after installation to staging Currently we configure uClibc to use kernel headers from "staging" folder with KERNEL_HEADERS="$(STAGING_DIR)/usr/include". This path is added to include search path of uClibc build system in Rules.mak "CFLAGS += -I$(KERNEL_HEADERS)". At the same time on uClibc installation to "staging" we point to the same location "$(STAGING_DIR)/usr" (headers effectively go in "usr/include"). So after every installation to "staging" dependences get touched (even though we copy the same headers every time) and so we may see lots of sources in uClibc get rebuilt. This has 2 consequences: 1. Longer build time - becase even on ordinary buildroot build uClibc is built twice. On "uclibc building" and on "uclibc installation to target". 2. Symbols in libuClibc built initially (that is later installed in "staging/sysroot") are situated with different offset compared to second build (later copied in "target"). This happens because as described above only part of sources get rebuilt and then on final linkage object files are linked in different order. And (2) leads to problems on remote rebugging: gdbserver reports offsets that correspond to pointless assembly in libuClibc on host. Here's how it looks like. Before this patch: $ cd ~/br2_output/i586/target/lib $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill 423: 0000c42c 54 FUNC GLOBAL DEFAULT 7 kill $ cd ~/br2_output/i586/staging/lib $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill 423: 0000b518 54 FUNC GLOBAL DEFAULT 7 kill After this patch: $ cd ~/br2_output/i586/target/lib $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill 423: 0000b518 54 FUNC GLOBAL DEFAULT 7 kill $ cd ~/br2_output/i586/staging/lib $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill 423: 0000b518 54 FUNC GLOBAL DEFAULT 7 kill Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Noam Camus <noamc@ezchip.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-06-04 22:27:33 +02:00
$(TARGET_MAKE_ENV) $(MAKE) \
ARCH=$(KERNEL_ARCH) \
HOSTCC="$(HOSTCC)" \
HOSTCFLAGS="$(HOSTCFLAGS)" \
HOSTCXX="$(HOSTCXX)" \
package/linux-headers: add option to use same sources as the kernel Some heavily (and most often improperly) modified Linux kernels may export new APIs to userland, so as to speak to custom hardware or custom kernel facilities. However, we currently have no easy way to use such kernels as a source for the linux-headers package, which precludes having those userland headers intalled for userland applications to use them. We do have a way for the kernel to use the same version as for the headers, but that is definitely not enough, as the linux-headers package has a version choice that is far less versatile and capable than that of the linux package. Add a new option for the linux-headers package, for the user to specify that the version (really, the sources) of the kernel be used to install the headers from. We do that by making linux-headers patch-depend on the linux package. We can't have linux-header simply depend on linux, because the simple dependency means the the dependee will be configured, built and installed before the dependent is configured. And since linux is a target package, it depends on the toolchain, which internally dependes on linux-headers, which would depend on linux, and we'd get a circular dependency. Using patch-depend will ensure that linux is extracted and patched before linux-headers is extracted, which is really all we need. Then, we install the headers from the linux source tree, rather than from linux-headers' source tree (as there's nothing in there!). Since we need to install a private set for uClibc (see cde947f, uclibc: prevent rebuilding after installation to staging), we explicitly set INSTALL_HDR_PATH when calling the kernel' install-headers rule in LINUX_HEADERS_CONFIGURE_CMDS, so that the headers are installed in linux-headers' $(@D) instead of linux' $(@D). Finally, as there is no way to know the kernel version in this case, we must still prompt the user for the kernel series the headers are from (like we do for a custom version) and check for consistency at build time. Note however that this still leaves users that want to built their such-kernel outside of Buildroot out in the cold. [Peter: drop comment as suggested by Thomas] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Karoly Kasza <kaszak@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-20 19:34:28 +01:00
INSTALL_HDR_PATH=$(@D)/usr \
uclibc: prevent rebuilding after installation to staging Currently we configure uClibc to use kernel headers from "staging" folder with KERNEL_HEADERS="$(STAGING_DIR)/usr/include". This path is added to include search path of uClibc build system in Rules.mak "CFLAGS += -I$(KERNEL_HEADERS)". At the same time on uClibc installation to "staging" we point to the same location "$(STAGING_DIR)/usr" (headers effectively go in "usr/include"). So after every installation to "staging" dependences get touched (even though we copy the same headers every time) and so we may see lots of sources in uClibc get rebuilt. This has 2 consequences: 1. Longer build time - becase even on ordinary buildroot build uClibc is built twice. On "uclibc building" and on "uclibc installation to target". 2. Symbols in libuClibc built initially (that is later installed in "staging/sysroot") are situated with different offset compared to second build (later copied in "target"). This happens because as described above only part of sources get rebuilt and then on final linkage object files are linked in different order. And (2) leads to problems on remote rebugging: gdbserver reports offsets that correspond to pointless assembly in libuClibc on host. Here's how it looks like. Before this patch: $ cd ~/br2_output/i586/target/lib $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill 423: 0000c42c 54 FUNC GLOBAL DEFAULT 7 kill $ cd ~/br2_output/i586/staging/lib $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill 423: 0000b518 54 FUNC GLOBAL DEFAULT 7 kill After this patch: $ cd ~/br2_output/i586/target/lib $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill 423: 0000b518 54 FUNC GLOBAL DEFAULT 7 kill $ cd ~/br2_output/i586/staging/lib $ i586-buildroot-linux-uclibc-readelf -s libuClibc-0.9.33.2.so | grep kill 423: 0000b518 54 FUNC GLOBAL DEFAULT 7 kill Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Noam Camus <noamc@ezchip.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-06-04 22:27:33 +02:00
headers_install)
endef
kernel-headers: migrate to the package infrastructure [Peter: fix file header] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-06-30 21:28:58 +02:00
define LINUX_HEADERS_INSTALL_STAGING_CMDS
linux-headers: fix circular dependency when HEADERS_AS_KERNEL is used The linux-headers -> linux dependency causes a circular dependency, breaking the source/legal-info/graph-depends/.. targets: make graph-depends Getting targets Getting dependencies for ['toolchain-buildroot', 'toolchain', 'busybox', 'glibc', 'initscripts', 'linux-headers', 'skeleton', 'linux', 'host-fakeroot', 'host-makedevs', 'rootfs-cpio', 'rootfs-initramfs'] Getting dependencies for ['host-kmod', 'host-gcc-final', 'host-gcc-initial', 'host-gawk'] Getting dependencies for ['host-gmp', 'host-binutils', 'host-pkgconf', 'host-mpfr', 'host-mpc'] Getting dependencies for ['host-m4'] Recursion detected for : toolchain which is a dependency of: linux which is a dependency of: linux-headers which is a dependency of: glibc which is a dependency of: host-gcc-final which is a dependency of: toolchain-buildroot which is a dependency of: toolchain Makefile:721: recipe for target 'graph-depends' failed make: *** [graph-depends] Error 1 Fix it by instead duplicating in linux-headers the 10-20 lines of linux.mk logic that infer the _SOURCE/_SITE/_VERSION from the BR2_LINUX_KERNEL_* variables. This does mean that we extract the kernel sources twice though. [Peter: use same git/hg tarball as linux kernel to not clone twice, minor fixes] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-02-24 15:04:09 +01:00
(cd $(@D); \
kernel-headers: migrate to the package infrastructure [Peter: fix file header] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-06-30 21:28:58 +02:00
$(TARGET_MAKE_ENV) $(MAKE) \
ARCH=$(KERNEL_ARCH) \
HOSTCC="$(HOSTCC)" \
HOSTCFLAGS="$(HOSTCFLAGS)" \
HOSTCXX="$(HOSTCXX)" \
INSTALL_HDR_PATH=$(STAGING_DIR)/usr \
headers_install)
endef
package/linux-headers: add support for fetching from custom tarball/git Add support for building toolchains against custom headers. Allows the selection of a manual version, custom tarball or custom git repository for the kernel headers. This enables toolchains to be built against custom kernel headers without having to build a full kernel. This is particularly useful for new architectures, such as RISC-V where updated kernel headers may not have made it into the mainline kernel yet. Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-23 21:43:12 +02:00
ifeq ($(BR2_KERNEL_HEADERS_VERSION)$(BR2_KERNEL_HEADERS_AS_KERNEL)$(BR2_KERNEL_HEADERS_CUSTOM_TARBALL)$(BR2_KERNEL_HEADERS_CUSTOM_GIT),y)
toolchain: allow using custom headers newer than latest known ones When Buildroot is released, it knows up to a certain kernel header version, and no later. However, it is possible that an external toolchain will be used, that uses headers newer than the latest version Buildroot knows about. This may also happen when testing a development, an rc-class, or a newly released kernel, either in an external toolchain, or with an internal toolchain with custom headers (same-as-kernel, custom version, custom git, custom tarball). In the current state, Buildroot would refuse to use such toolchains, because the test is for strict equality. We'd like to make that situation possible, but we also want the user not to be lenient at the same time, and select the right headers version when it is known. So, we add a new Kconfig blind option that the latest kernel headers version selects. This options is then used to decide whether we do a strict or loose check of the kernel headers. Suggested-by: Aaron Sierra <asierra@xes-inc.com> Signed-off-by: Vincent Fazio <vfazio@xes-inc.com> [yann.morin.1998@free.fr: - only do a loose check for the latest version - expand commit log ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Tested-by: Vincent Fazio <vfazio@xes-inc.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-01-15 19:29:07 +01:00
# In this case, we must always do a 'loose' test, because they are all
# custom versions which may be later than what we know right now.
toolchain/internal: check kernel headers version for manually-specified version Ensure the kernel headers version matches exactly the one manually specified by the user. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-01 15:53:02 +01:00
define LINUX_HEADERS_CHECK_VERSION
$(call check_kernel_headers_version,\
toolchain: generate check-headers program under $(BUILD_DIR) Some installations mount /tmp with the 'noexec' option, which prevents running the program generated there to check the kernel headers. Avoid the problem by generating the program under $(BUILD_DIR), passed as the first argument to check-kernel-headers.sh. We could globally export a TMPDIR environment variable with some path under $(BUILD_DIR) but such solution would be too intrusive, depriving the user from the freedom to set TMPDIR at his will (or needs). Fixes: https://bugs.busybox.net/show_bug.cgi?id=12241 Signed-off-by: Carlos Santos <unixmania@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-09-24 13:46:11 +02:00
$(BUILD_DIR),\
support/check-kernel-headers: fix old custom toolchains without -print-sysroot Old toolchains, with old gcc that do not support -print-sysroot, break the kernel-headers version check script: it fails to find the sysroot of the toolchain, and thus ends up including the host's linux/version.h. Most of the time, this will break early, since the host's kernel headers will not match the toolchain settings. But it can happen that the check is succesful, although the configuration of the toolchain is wrong: - the custom toolchain has kernel headers vX.Y - the user selected vX.Z (Z!=Y) - the host has headers vX.Y In this case, the check passes OK, but the build of some packages later on will break (which is exactly what those _AT_LEAST_XXX options were added to avoid). Fix that by passing the sysroot to the check script, instead of the cross compiler. We get the sysroot as thus: - for custom toolchains, we use the macro toolchain_find_sysroot. We can do that, because we already have a complete sysroot with libc.a at that time. - for internal toolchain using a custom kernel headers version, we just use $(STAGING_DIR). We can't use the macro as for custom toolchains above, because at the time we install the kernel headers, we do not yet have a complete sysroot with a libc.a. But we can just use $(STAGING_DIR), since we're only interested in the kernel headers. For all other types of toolchains, we already have the _AT_LEAST_XXX options properly set, so we need not add a check in this case. Fixes: http://autobuild.buildroot.net/results/f33/f331a6eff0b0b93c73af52db3a6b43e4e598577e/ http://autobuild.buildroot.net/results/a57/a5797c025bec50c10efdcff74945aab4021d05e4/ [...] [Thanks to Thomas for pointing out the toolchain_find_sysroot macro!] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-04-07 20:19:12 +02:00
$(STAGING_DIR),\
toolchain: allow using custom headers newer than latest known ones When Buildroot is released, it knows up to a certain kernel header version, and no later. However, it is possible that an external toolchain will be used, that uses headers newer than the latest version Buildroot knows about. This may also happen when testing a development, an rc-class, or a newly released kernel, either in an external toolchain, or with an internal toolchain with custom headers (same-as-kernel, custom version, custom git, custom tarball). In the current state, Buildroot would refuse to use such toolchains, because the test is for strict equality. We'd like to make that situation possible, but we also want the user not to be lenient at the same time, and select the right headers version when it is known. So, we add a new Kconfig blind option that the latest kernel headers version selects. This options is then used to decide whether we do a strict or loose check of the kernel headers. Suggested-by: Aaron Sierra <asierra@xes-inc.com> Signed-off-by: Vincent Fazio <vfazio@xes-inc.com> [yann.morin.1998@free.fr: - only do a loose check for the latest version - expand commit log ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Tested-by: Vincent Fazio <vfazio@xes-inc.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-01-15 19:29:07 +01:00
$(call qstrip,$(BR2_TOOLCHAIN_HEADERS_AT_LEAST)),\
loose)
toolchain/internal: check kernel headers version for manually-specified version Ensure the kernel headers version matches exactly the one manually specified by the user. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-01 15:53:02 +01:00
endef
LINUX_HEADERS_POST_INSTALL_STAGING_HOOKS += LINUX_HEADERS_CHECK_VERSION
endif
kernel-headers: migrate to the package infrastructure [Peter: fix file header] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-06-30 21:28:58 +02:00
$(eval $(generic-package))
Reference in New Issue Copy Permalink