For most defconfigs, it was trivial to deduce the kernel version, by
just reading the version string, which could be:
- a standard upstream version string vX.Y.Z
- a non-standard version string, but still containg the standard X.Y.Z
Those for which it was not so trivial were those hosted on git tree.
Since most were already using a custom linux-headers version, it could
be easily deduced from that. It was confirmed by browsing said git trees
and check the version there.
There are a few cases were there was a mismatch:
- microzed: uses a 3.18 kernel, but 3.8 headers; fixed.
- xilinx_zc706: uses a 3.14 kernel, but 3.8 headers; fixed.
- zedboard: uses a 3.18 kernel, but 3.8 headers; fixed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since commit 2a5cf5e (check kernel headers version), we also need to
specify the series of the custom kernel headers version.
The defconfigs file that define such a custom kernel headers version
now fail to build.
Add the required _AT_LEAST_X_Y options to those config files. Done with
this (convoluted but very fast, uch faster ythan manual editing!) rule:
for f in $( git grep -l BR2_DEFAULT_KERNEL_VERSION=\"3 ); do
grep -E '^BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_' "${f}" >/dev/null && continue
sed -r -e '/^(BR2_DEFAULT_KERNEL_VERSION="3\.([[:digit:]]+).*")$/s//\1\nBR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_\2=y/' "${f}"
done
Only kernels >= 3.0 need those options in the defconfig, since the
default for 2.6.x kernels is correct (selects _AT_LEAST_2_6), and
the default is not saved in a defconfig.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Peter: also add to 9g0dfc]
Signed-off-by: Alexandre Belloni <alexandre.belloni@piout.net>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
It's pretty uncommon to use ext2fs on embedded systems, so don't enable
it by default.
Adjust defconfigs to match.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Use modern U-Boot and kernel versions, get rid of the now unused
kernel configuration file since we use the kernel defconfig instead.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The configuration cache shared between packages, while being in
principle a nice idea to speed-up the configuration of packages by
avoiding repetitive identical checks, turned out to be unreliable due
to the subtle differences between similar but not identical checks in
different packages. After spending some time trying to fix those, we
concluded that supporting the shared configuration cache is definitely
too hard and too unreliable, and that we'd better get rid of it
altogether.
This patch therefore removes the shared configuration cache
infrastructure and usage.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
As stated on http://pcmcia-cs.sourceforge.net/: "The Linux pcmcia-cs
package is officially deprecated. It can only be used with 2.4 and
older kernels.".
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Supporting multilib is much more than just passing --enable-multilib
to gcc. You have to actually build the C library several times (once
for each multilib variant you want to support in your toolchain), and
to pass MULTILIB_OPTIONS/MULTILIB_EXCEPTIONS values to gcc to let it
know the set of multilib variants you're interested in.
Since we'll probably never support multilib toolchains in Buildroot,
just get rid of this BR2_ENABLE_MULTILIB option.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This is a very advanced option, and it seems, according to
http://choices.cs.uiuc.edu/exceptions.pdf that SJLJ exceptions aren't
really interesting.
Users really interested by this can always use the
BR2_EXTRA_GCC_CONFIG_OPTIONS is they want.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The buildroot/busybox/uClibc VM is running low on disk space, and we've
been asked to move the source mirrors off-site.
A redirect has been setup between the old buildroot.net/downloads/sources/
and sources.buildroot.net, so old .configs continue to work, but we might
as well use the official one now.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
We only bother updating the defconfigs that need a non-default
BR2_ROOTFS_DEVICE_TABLE value.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported by Grant Edwards <grant.b.edwards@gmail.com>
Use the new default STAGING_DIR location (output/staging) in all the
defconfigs for clarity.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Invert the BR2_PACKAGE_BUSYBOX_HIDE_OTHERS option to use positive logic,
renaming it to _SHOW_OTHERS.
Positive logic is simpler to understand, and it makes all{,package}config
do the right thing.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
As discussed earlier on the mailing list. It simplifies code, gives more
sensible error message on typos and makes the defconfigs easier to find
for users.
Furthermore, update documentation to match.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
