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>
Commit a5e92d92e7 converted uClibc to the
package infrastructure, but while doing so removed support for the
documented uclibc-update-config make target. This make target copies the
uclibc .config file back to the original (typically version-controlled)
configuration file.
As this was an unintentional removal, this patch re-adds the
uclibc-update-config target.
Reported-by: Dan Moulding <dan.moulding@rackwareinc.com>
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The package infrastructure add automatically the "dirs" dependency so
remove it when the package infrastructure is being used.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The three typical packages that use .config files in buildroot copy the
config file at different times in the build process:
busybox copies its .config from the post-extract hook.
linux copies its .config in the configure_cmds.
uclibc copies its .config from the post-patch hook.
Copying the .config file from the configure step is the only way to properly
support an OVERRIDE_SRCDIR that does not yet have the .config file, because
the extract and patch steps are skipped in that case.
In a previous patch, the situation was already fixed for busybox. This patch
applies the same fix to uclibc: copy the config file from the configure
step, as linux is doing.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To be able to use top-level parallel make we must not depend in a rule
on the order of evaluation of the prerequisites, so instead of relying
on the left to right ordering of evaluation of the prerequisites add
an explicit rule to describe the dependencies.
We cannot use the pattern rules because they must have the same
dependency for every package, but we need to change the dependencies
depending on $(2)_OVERRIDE_SRCDIR variable value, so we must use a
more flexible way like $(2)_TARGET_% variables.
So add explicit dependencies for the following stamp files:
$(2)_TARGET_EXTRACT
$(2)_TARGET_PATCH
$(2)_TARGET_CONFIGURE
$(2)_TARGET_BUILD
$(2)_TARGET_INSTALL_STAGING
$(2)_TARGET_INSTALL_TARGET
$(2)_TARGET_INSTALL_IMAGES
$(2)_TARGET_INSTALL_HOST
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
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>
If $(UCLIBC_CONFIG_FILE) is read-only (eg. because Buildroot's
source dir is), the sed fixups to .config fail.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
[yann.morin.1998@free.fr: use $(INSTALL) instead of cp]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, the Xtensa architecture uses the "snapshot" version of
uClibc. This means that the build is not reproducible, since it will
pick whatever latest version of uClibc is available at the moment of
the build.
This commit replaces that by adding a special Xtensa version, which
points to a well-known Git commit. This is something we should
hopefully be able to remove once the uClibc people realize that doing
a 0.9.34 release would be useful.
Should probably fix:
http://autobuild.buildroot.org/results/5d6/5d6072a038acf894d832704e36c1d43f0254abf5/build-end.log
at least I wasn't able to reproduce the build problem.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[baruch: use a more recent uClibc version]
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The DODEBUG configuration option in uClibc is broken, even for widely
used architectures like ARM. Therefore, any Buildroot configuration
that has BR2_ENABLE_DEBUG enabled and uses uClibc with the internal
toolchain backend will fail, with an error like:
http://autobuild.buildroot.net/results/d34/d34238c209cf2ef63371a598ab9218165c90f864/build-end.log
This error was also reported recently by a Buildroot user.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
While the idea of skipping the intermediate gcc step seems to work
fine in most situations, it causes problems with the SSP
support. Until we can figure out a proper solution for this problem,
we need to revert back to the previous solution of a three stages
build.
This reverts commit 2babed4a50.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
commit c798bec25 "uclibc: set MMU usage accordingly" defines UCLIBC_MMU_CONFIG,
but forgot adding it to UCLIBC_SETUP_DOT_CONFIG. Fix it.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When NPTL support was introduced, gcc required a three stages build
process. Since gcc 4.7, this is no longer necessary, and it is
possible to get back to a two stages build process. This patch takes
advantage of this, by doing a two stages build process when possible.
We introduce a few hidden kconfig options:
* BR2_GCC_VERSION_NEEDS_THREE_STAGE_BUILD, which is set by the gcc
Config.in logic to indicate that the compiler might need a three
stages build. Currently, all versions prior to 4.7.x are selecting
this kconfig option.
* BR2_TOOLCHAIN_LIBC_NEEDS_THREE_STAGE_BUILD, which indicates whether
the C library might need a three stages build. This is the case for
eglibc, and uClibc when NPTL is enabled.
* BR2_TOOLCHAIN_NEEDS_THREE_STAGE_BUILD finally is enabled when both
of the previous options are enabled. It indicates that a three
stages build is actually needed.
In addition to those options, the uClibc/gcc build logic is changed to
use only a two stages build process when possible.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
On architectures that lack a MMU (like blackfin) uclibc just undefined
ARCH_HAS_MMU which disabled ARCH_USE_MMU.
But for other architectures which may or may not have one like ARM we
need to set this according to user choice.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When BR2_UCLIBC_ARM_BX is not set, UCLIBC_OPT_UNSET gets called with an extra
argument. Remove it.
Signed-off-by: Justin Maggard <jmaggard10@gmail.com>
Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that we've dropped 0.9.31.x we can use the startfiles /
install_startfiles targets instead of building and installing them by
hand.
Fixes internal blackfin toolchain build errors regarding crtreloc.o
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
These are broken for blackfin unfortunately so they're disabled.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current SSP handling is incomplete.
First we need to build uClibc with SSP support for a complete
"experience".
Second, it doesn't hurt to add -fstack-protector-all to the
CFLAGS/CXXFLAGS since most users would expect buildroot to do this
rather than adding the flags themselves.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It runs out of registers, it fails even in official form
(COMPILE_IN_THUMB_MODE=y) so just build it in ARM mode since EABI
mandates interworking.
Tested in an arm920t board.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
These were required with ARC gcc 4.4.7; ARC gcc 4.8 has been changed
to behave the same as other architectures with -nostdlib, making this
option obsolete.
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
With the move of uclibc to package/uclibc, the uclibc-menuconfig target now
depends on uclibc-configure, which brings in the build of
binutils/gcc-initial/mpfr/gmp, causing it to take ages with a clean tree.
Fix it by moving the basic .config mangling to the patch step, and depend
on that for menuconfig instead.
Notice that this is broken for _OVERRIDE_SRCDIR users, just like for
busybox, but as that is presumably a small subset of the buildroot
user base (and these advanced users can just run menuconfig in their
local uClibc tree), so this is considered the lesser evil of the two.
The proposed out-of-tree build series will also cause problems with
this.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
... since we now only support EABI for ARM, we only need to
force EABI unconditionally.
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>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
[Peter: update manual to match]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
