The C program inside check-kernel-headers.sh has two checking mode: a
strict and a loose one.
In strict mode, we want the kernel headers version declared by the
user to match exactly the one of the toolchain.
In loose mode, we want the kernel headers version of the toolchain to
be greater than or equal to the one declared by the user: this is used
when we have a toolchain that has newer headers than the latest
version known by Buildroot.
However, in loose mode, we continue to show the "Incorrect kernel
headers version" message, even though we then return a zero error
code. This is very confusing: you see an error displayed on the
terminal, but the build goes on.
We fix that by first doing the loose check first, and returning 0 if
it succeeds. And then we move on with the strict check where we want
the version to be identical.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Most, but not all our C code follows the Linux kernel code style (as
documented in Documentation/process/coding-style.rst). Adjust the few
places doing differently:
- Braces:
..but the preferred way, as shown to us by the prophets Kernighan
and Ritchie, is to put the opening brace last on the line
- Spaces after keywords:
Use a space after (most) keywords
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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>
The POSIX specification defines a 'trap <action> EXIT' mechanism that is
useful to perform clean-up actions in shell scripts. A trap has two main
advantages over hand-crafted clean-up mechanisms:
- It runs even if the process is terminated by a SIGTERM.
- It runs even if the script stops due to a pipeline failure (set -e).
Now we can make the script to stop immediately if a compilation error
occurs, instead of letting it try to run an unexisting program.
This change may appear to be overkill but Buildroot is an open source
project and each piece of code is a potential learning tool for other
developments. We must strive to provide good examples.
Signed-off-by: Carlos Santos <unixmania@gmail.com>
Acked-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
mktemp --tmpdir is not available on older Redhat RHEL5 machines. The
alternative that has the same behavior is 'mktemp -t'.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
Instead of creating a temporary files with a dubious scheme, use mktemp,
which purpose is exactly that: creating temporary files
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since we introduced the _AT_LEAST_XXX for the kernel headers, people
using pre-built custom toolchain now have to specify the version of
the kernel headers their custom toolchain uses.
So, when we detect that there is a mismatch between the selection in
the menuconfig, and the actual version of the headers, we currently
only bail out with a terse message "Incorrect selection of kernel
headers".
This could be confusing some, and getting the version of the headers
used by the toolchain is not trivial (well, it's very easy, but not
trivial.)
This patch changes the way we report the error by moving the message
into the test-code, and by printing the expected and actual versions
of the kernel headers.
BUT! To get this pretty error message, we need to run the
test-program, so we can not use the cross-toolchain, we have to use
the native one.
BUT! The native one has its own linux/version.h header, so we can not
simply include it.
So, we ask the cross-compiler where its default sysroot is, and use
that to then force-feed the cross linux/version.h to the native
toolchain.
[Thomas: augment commit log with a message provided by Yann, fix
coding style to not have spaces after opening parenthesis and before
closing parenthesis, reformatted the message "Incorrect selection..."
to make it fit on one line.]
Reported-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Ensure the kernel headers version used in the custom external toolchain,
or the manually-specified kernel headers version, matches exactly the one
selected by the user.
We do not care about the patch-level, since headers are not supposed to
change between patchlevels. This applies only to kernels >= 3.0, but
those are actually the ones we do care about; we treat all 2.6.x kernels
as being a single version, since we do not support any 2.6 kernels for
packages with kernel-dependant features.
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>
