As our architecture support expands to a number of architectures that
do not implement NPTL threading, and the number of packages that
depend on NPTL specific features, it has become necessary to be able
to know whether the toolchain has NPTL support or not.
This commit adds a new BR2_TOOLCHAIN_HAS_THREADS_NPTL hidden Config.in
option that allows packages to know whether NPTL is available or not.
This hidden option is:
* Automatically enabled when glibc/eglibc or musl toolchains are
used, either internal or external.
* Automatically enabled when an internal uClibc toolchain with NPTL
support is configured. It is left disabled otherwise for internal
uClibc toolchains.
* Configured according to a visible Config.in option for custom
external uClibc toolchains.
[Peter: factor _EXTERNAL_HAS_THREADS in single if as suggested by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch removes the sh2, sh3 and sh3eb support, because the user
base is inexistent, and the Linux support for these architectures is
poor. The sh2a support is preserved, because at least one user
expressed interest in this architecture, and is actually using it:
http://lists.busybox.net/pipermail/buildroot/2013-April/070399.html
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The uClibc options for sh2a is SH2A, not SHA2, and this value should
be used for sh2a, not sh2.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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 BR2_UCLIBC_MIPS_ISA hidden Config.in variable defines which uClibc
config option should be enabled for a given MIPS architecture
variant. Therefore, using lower case names doesn't work: they should
be upper case, to match uClibc config option names. This commit makes
sure the mips32, mips32r2 and mips64 builds select the appropriate
uClibc configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Markos Chandras <Markos.Chandras@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch reinstates support for uClibc version 0.9.31, which was removed
from Buildroot in commit 8abb5b33c1
Signed-off-by: Simon Dawson <spdawson@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some Config.in(.host) files have constructs like:
config FOO_VERSION
string
default "1.0" if FOO_1_0
default "2.0" if FOO_2_0
default $FOO_CUSTOM_VERSION if FOO_CUSTOM
The dollar sign here is not needed and confusing, so can be removed.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The e500mc core has a classic FPU, SPE is a bad word.
See: http://en.wikipedia.org/wiki/PowerPC_e500#e500mc
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
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>
This commit refactors how Stack Smashing Protection support is handled
in Buildroot:
*) It turns the BR2_TOOLCHAIN_BUILDROOT_USE_SSP option into an option
that only enables the SSP support in uClibc, when using the internal
toolchain backend.
*) It adds an hidden BR2_TOOLCHAIN_HAS_SSP option that gets enabled
when the toolchain has SSP support. Here we have the usual dance:
glibc/eglibc in internal/external backend always select this
option, in the case of uClibc/internal, it gets selected when
BR2_TOOLCHAIN_BUILDROOT_USE_SSP is enabled, in the case of
uClibc/external, there is a new configuration option that the user
must select (or not) depending on whether the toolchain has SSP
support.
*) It adds a new options BR2_ENABLE_SSP in the "Build options" menu,
to enable the usage of SSP support, by adding
-fstack-protector-all to the CFLAGS.
Signed-off-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>
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>
[Thomas: do not reorder options, as this is a separate change]
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>
... 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>
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>
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>
Using the newly introduced 'eglibc' package, this commit enables the
option of building a toolchain using the eglibc C library in the
Buildroot toolchain backend.
In details, this commit:
* Creates a choice to select uClibc or eglibc in the Buildroot
toolchain backend (in toolchain/toolchain-buildroot/Config.in), and
removes the fact that the Buildroot toolchain backend forcefully
enables uClibc (toolchain/Config.in).
* Creates a BUILDROOT_LIBC variables, which points to the package
implementing the C library (i.e either 'uclibc' or 'eglibc').
* Modifies the gcc-final and gcc-intermediate makefiles to use the
BUILDROOT_LIBC variable instead of hardcoding the use of uclibc.
* Ensures that TLS support is always enabled when building eglibc.
[Peter: fix commit text to refer to BUILDROOT_LIBC]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
In preparation for the introduction of the eglibc library to the
internal toolchain backend, the options that allow to enable/disable C
library features such as largefile, IPv6, RPC and so on now belong to
the uClibc package.
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>
