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>
Kernel headers version 3.8.x has been deprecated since 2013.08 and thus can
be removed in 2014.08.
An automatic selection of 3.9.x headers is performed in the legacy menu.
Existing automatic selections of 3.8.x headers are modified to select
3.9.x.
As this patch removes the last occurrence of BR2_DEPRECATED_SINCE_2013_08,
the symbol is removed too.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Kernel headers versions 3.6.x and 3.7.x have been deprecated since 2013.05
and thus can be removed in 2014.05.
An automatic selection of 3.8.x headers is performed in the legacy menu.
An existing automatic selection of 3.6.x headers is modified to select
3.8.x.
As this patch removes the last occurrances of BR2_DEPRECATED_SINCE_2013_05,
the symbol is removed too.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit 971e331c54
('package/linux-headers: remove 2.6 snapshot'), we removed the support
for the Linux headers snapshot option, but we forgot to remove some
related help text in the main Config.in option of the Linux headers
package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.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>
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>
Select the appropriate BR2_TOOLCHAIN_HEADERS_AT_LEAST_XXX options for the
internal toolchain backend.
For the manualy-specified version, we bring up the choice that sets the
_AT_LEAST_XXX symbols.
[Thomas: rename symbols from BR2_PACKAGE_HOST_LINUX_HEADERS_<version>
to BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_<version> to clearly indicate
that they are used to specify the version of custom headers.]
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>
Cc: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As Thomas states:
It is completely weird to ask the tarball to be named exactly
linux-2.6.tar.bz2. IMO, we should simply get rid of this feature.
Make it so! ;-)
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>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
3.3.8 support is removed since 334dca61 (kernel-headers: remove deprecated
versions 3.1, 3.3, 3.5), so let's get rid of the patch as well.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
The Linux kernel headers versions 3.1, 3.3, and 3.5 have been deprecated
since 2013.02 and thus can be removed in 2014.02.
For legacy handling, we automatically select versions 3.2, 3.4, and 3.6,
respectively.
Additionally, this patch removes the now unused symbol
BR2_DEPRECATED_SINCE_2013_02.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In order to keep better track of when a feature got deprecated, and hence
when it can be removed, a new set of symbols BR2_DEPRECATED_SINCE_xxxx_xx is
introduced. These symbols are automatically selected when BR2_DEPRECATED is
selected, and thus are transparent to the user.
A deprecated feature will no longer depend on BR2_DEPRECATED directly, but
rather on the appropriate BR2_DEPRECATED_SINCE_xxxx_xx. If that symbol does
not yet exist, it has to be created in Config.in.
When removing a deprecated feature, one should also check whether this was
the last feature using the BR2_DEPRECATED_SINCE_xxxx_xx symbol, in which
case the latter can be removed from Config.in.
A followup patch will make sure the overview is added to the list of
deprecated features in the manual, so that a buildroot core developer can
easily determine which features to remove in a given development cycle.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
