As discussed during the ELCE 2012 Buildroot Developers Meeting, we no
longer want to support the possibility of building a toolchain for the
target. None of the core developers have any use for this, it has been
known to be broken or cause problems for a long time without anyone
providing fixes for it.
In addition to this, Buildroot is inherently a cross-compilation tool,
so the usage of a native toolchain on the target is not really
useful. Many newcomers are tempted to use this possibility even though
it is clearly not the intended usage of Buildroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Xtensa is a configurable processor architecture, which allows to define
additional instructions and registers. The required variant specific
information for the toolchain is delivered in an 'overlay' file, which
needs to be 'untarred' to the corresponding directories after the
source is installed and patched.
This patch provides support for binutils, gcc, and gdb with a very
limited changes to the build scripts. These additions are only executed
for the Xtensa architecture and have no effect on other architectures.
[Thomas: rebased on top of the 'arch: improve definition of gcc mtune,
mcpu, etc.' patch, and changed 'Target ABI' to 'Target Architecture
Variant'].
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The Xtensa architecture had been removed because it required special
handling and depended on additional directories and files that became
obsolete over time. This change is more aligned to other architectures.
[Thomas: rebased on top of the "arch: improve definition of gcc mtune,
mcpu, etc." patch].
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This patch has since a long time been merged upstream in uClibc, so it
cannot apply on any of the recent uClibc snapshots.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Basically, the BR2_TOOLCHAIN_EXTERNAL_GLIBC option no longer
unconditionally selects BR2_TOOLCHAIN_HAS_NATIVE_RPC since there are
glibc toolchains that don't have RPC support. All the predefined
toolchain profiles are updated to take into account this change: for
the moment, all glibc toolchains that have pre-defined toolchains have
RPC support, but further patches in the series add pre-defined glibc
toolchains that don't have RPC support. In the case of custom glibc
toolchains, a question is asked to the user so that he can say whether
the external glibc toolchain has RPC support or not. The validity of
this configuration option is checked by the new
check_glibc_rpc_feature function in helpers.mk.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The BR2_INET_RPC has for a long time been a not very descriptive
configuration option name, and with the advent of non-RPC glibc
toolchains and the apparition of libtirpc, we really need to rename it
to something more sensible, BR2_TOOLCHAIN_HAS_NATIVE_RPC.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Since we are some day going to finally rename the badly named common
toolchain options (BR2_USE_WCHAR, BR2_ENABLE_LOCALE, BR2_INET_RPC,
etc.) into something more logical, let's start using the Crosstool-NG
toolchain options in the Crosstool-NG code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Since we are some day going to finally rename the badly named common
toolchain options (BR2_USE_WCHAR, BR2_ENABLE_LOCALE, BR2_INET_RPC,
etc.) into something more logical, let's start using the Buildroot
toolchain options in the uClibc code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When an external toolchain without thread debug is used, the gdb
package can be selected, but no version can be choosen, since none
match any of the requirements. This leads Buildroot to try to build
gdb for the target without a version being defined, as in the
following build log:
http://autobuild.buildroot.org/results/84e8fd2df0cc22448052a572c2e9a6e03dd137eb/build-end.log
To fix this, we adjust the dependencies of the BR2_PACKAGE_GDB option
so that the package as a whole is not selectable when the required
conditions are not met. Basically, we have the choice of:
* Having a toolchain that supports thread debugging, which is needed
for gdb >= 7.x
* Having BR2_DEPRECATED enabled, which allows gdb 6.8 to be selected,
which doesn't require thread debugging
* Using bfin, since this architectures has a special old gdb version
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Our internal toolchain backend does not yet have support for AArch64,
and Crosstool-NG also does not have support for AArch64 at the moment
(though it should be coming quickly since the Linaro AArch64 toolchain
is generated with a modified Crosstool-NG version).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
ld-linux*.so may not be present in lib/ directory, it could be
in lib32 and/or lib64 only. But check_glibc reports
"Incorrect selection of the C library" in this case, which is
not true.
Fixed by extending the search to SYSROOT/*/*.
Signed-off-by: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Since 11017f081f, the Crosstool-ng
backend generates toolchains that have a prefix inconsistent with what
Buildroot expects. Buildroot expects a "buildroot" vendor name, while
Crosstool-NG builds toolchain with the "unknown" vendor name.
This is causing build failure such as:
http://autobuild.buildroot.org/results/15b2c0e50a81b86dd13af684c9254df2bc0df8de/build-end.log
Fix this by changing the vendor part of the tuple used by Crosstool-NG
to "buildroot".
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Yann E. MORIN says:
"Although eglibc can be configured to include/exclude parts of the
features, it seems to not be in wide use, if at all."
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
As stated in commit 555c2585bf, the
Xtensa architecture has been introduced in 2009 and never changed
since its initial introduction. It requires some special handling that
is a bit annoying, and despite our call to the initial developers, and
the announcement of the deprecation of the architecture during the
2012.05, nothing has happened. Therefore, drop support for this
architecture.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: me
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
BR2_SPARC_TYPE is a hidden configuration option that is only used for
the configuration of uClibc, therefore, we move it from
target/Config.arch.in to toolchain/uClibc/Config.in.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
