Commit Graph

61 Commits

Author SHA1 Message Date
Thomas Petazzoni
07bb65c657 package, toolchain: remove BR2_TOOLCHAIN_HAS_GCC_BUG_* options
Quite some time ago, we added the options
BR2_TOOLCHAIN_HAS_GCC_BUG_58595 and BR2_TOOLCHAIN_HAS_GCC_BUG_58854 to
indicate if the toolchain was affected by those gcc bugs, which were
causing build failure with a number of packages.

With the recent change in the external toolchain logic to provide only
the latest version of each toolchain "family", all the toolchains
which were affected by those issues disappeared from Buildroot. Those
options are no longer being selected anywhere, and being blind
options, it means their value is always going to be "disabled".

Conquently, this commit removes those options completely, and updates
all the packages where they were used.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-30 11:02:30 +01:00
Gustavo Zacarias
df2ad61b5e toolchain: add 4.4.x choice for headers
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-11 17:32:41 +01:00
Vicente Olivert Riera
aef2df82e1 toolchain: add 4.3.x choice for headers
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: "James Knight" <james.knight@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-11-02 20:56:22 +01:00
Peter Korsgaard
8dc6829337 toolchain: add 4.2.x choice for headers
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-09-01 10:05:20 +02:00
Thomas Petazzoni
8ba2a76892 toolchain: add common gcc version hidden config options
This commit adds a number of hidden Config.in options, that will be
used to handle dependencies on the gcc version. We mimic the model
that was used for the kernel headers dependency mechanism.

These hidden options will be selected by the internal and external
toolchain backend logic respectively, in follow-up commits.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2015-08-05 10:40:19 +02:00
Gustavo Zacarias
dae7d8aa5d toolchain: add 4.1.x choice for headers
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-22 18:19:34 +02:00
Guido Martínez
29563047e0 arch: tidy up mmu config
Instead of blacklisting which architectures support MMUs (mandatorily
or optionally), introduce two Kconfig options that are selected by each
architecture in each case.

This simplifies the logic in BR2_USE_MMU.

Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-09 22:49:39 +02:00
Gustavo Zacarias
4bcacfd2c0 toolchain: drop BR2_INET_IPV6
It's no longer used so farewell.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-22 23:07:02 +02:00
Gustavo Zacarias
51eaa2ca15 toolchain: make IPv6 mandatory for external toolchains
Remove BR2_INET_IPV6 select for predefined external toolchains.

Remove the (non)IPv6 option prompt since it's now mandatory.

And force the toolchain check now that internal uclibc is always built
with IPv6 support and external non-IPv6 toolchains are disallowed.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-22 22:59:31 +02:00
Gustavo Zacarias
e714ee9412 toolchain: add 4.0.x choice for headers
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-13 22:14:42 +02:00
Gustavo Zacarias
1cb087b28b toolchain-common: drop BR2_LARGEFILE
It's now unused so remove it.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-01 22:53:41 +02:00
Gustavo Zacarias
f360fec787 toolchain-common: default to Y for LARGEFILE
This will allow us to remove largefile handling in the tree without
breaking things while doing so.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-01 22:42:32 +02:00
Peter Korsgaard
81366edd7c toolchain: add 3.19 choice for headers
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-02-09 13:31:23 +01:00
Yann E. MORIN
01c34b38a4 toolchain: get rid of -pipe from optimisations
-pipe is causing some build failures in Linux kernel >= 3.17.

Also, nowadays, using -pipe does not gain as much as it used to back in
the days:

Measurements made with a 3.16.7 Linux kernel:
    make linux-depends
    time sh -c 'make linux-build >/dev/null 2>&1'

Without -pipe:
    716.32user 54.44system 3:42.12elapsed 346%CPU
    721.22user 54.47system 3:41.81elapsed 349%CPU
    722.44user 54.00system 3:42.13elapsed 349%CPU
    721.03user 53.81system 3:41.92elapsed 349%CPU
    713.21user 53.63system 3:40.51elapsed 347%CPU
    706.67user 52.42system 3:38.40elapsed 347%CPU
    714.40user 53.18system 3:40.16elapsed 348%CPU
    706.01user 53.09system 3:37.87elapsed 348%CPU
    705.98user 53.01system 3:38.03elapsed 348%CPU
    714.17user 53.55system 3:39.98elapsed 348%CPU
Average:                   3:40.29elapsed

With -pipe:
    720.13user 53.90system 3:41.98elapsed 348%CPU
    713.38user 53.69system 3:40.44elapsed 347%CPU
    711.60user 52.81system 3:39.06elapsed 348%CPU
    708.66user 53.09system 3:38.59elapsed 348%CPU
    711.76user 53.00system 3:38.48elapsed 350%CPU
    717.85user 53.97system 3:41.77elapsed 348%CPU
    716.77user 53.77system 3:40.91elapsed 348%CPU
    717.48user 53.65system 3:41.24elapsed 348%CPU
    721.44user 55.67system 3:43.45elapsed 347%CPU
    724.61user 55.63system 3:43.35elapsed 349%CPU
Average:                   3:40.93elapsed

The delta is well in the measurement noise.

Just get rid of it.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@openwide.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-12-21 22:04:59 +01:00
Gustavo Zacarias
bf6f74de11 toolchain: add 3.18 choice for headers
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-12-08 13:10:30 +01:00
Thomas Petazzoni
cce0add500 toolchain: do not allow locale generation when locale support is not available
When the C library being used is uClibc, the locale support can be
disabled. In this case, it does not make sense to show the "Generate
locales" option.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-21 21:50:59 +01:00
Thomas Petazzoni
bd0ffe2206 toolchain: do not allow BR2_GENERATE_LOCALE with musl
Generating locales is possible in two situations:

 - With the internal toolchain backend, when the uClibc library is
   used. With uClibc, locales are generated at build time of the C
   library, so with uClibc it's only possible with the internal
   toolchain backend.

 - With either the internal or external toolchain backend when the
   glibc library is used. With glibc, locales can be generated
   afterwards, using the host-localedef utility.

Until we had the musl C library supported in the internal toolchain
backend, the condition: BR2_TOOLCHAIN_BUILDROOT ||
BR2_TOOLCHAIN_USES_GLIBC was correct to capture the above two
situations. Now that we have musl support in the internal toolchain
backend, then BR2_TOOLCHAIN_BUILDROOT is incorrect, and we should use
BR2_TOOLCHAIN_BUILDROOT_UCLIBC instead.

Basic locale support in musl has appeared in musl 1.1.4, but we are
not yet capable of generating the locale files for musl.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-21 21:50:42 +01:00
Gustavo Zacarias
2d312b7b61 toolchain: add 3.17 choice for headers
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-06 16:24:32 +02:00
Yann E. MORIN
6172ceb3cf toolchain: drop the now-unused old BR2_TOOLCHAIN_HAS_ATOMIC_INTRINSICS
It's now been replaced with BR2_ARCH_HAS_ATOMICS, annd all packages have
been changed to use that instead.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-08-18 10:57:55 +02:00
Yann E. MORIN
1b5f0fc8df arch: add an option to specify if the arch has atomic ops
The fact that atomic operations are available is not really a
specificity of the toolchain, but rather of the architecture.

So, add a new option that architectures that have atomic operations
can select. This in turn selects the current toolchain atomic option,
until all packages have been converted, at which point the old
toolchain option can be removed.

Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-08-18 10:56:35 +02:00
Gustavo Zacarias
911516f1b6 toolchain: add 3.16 choice for headers
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-04 09:46:41 +02:00
Anton Kolesov
cbffd50561 toolchain: Add config option for atomic intrinsics
GCC has several builtin functions that implement atomic operations. Those
functions are architecture specific and may not be implemented by the
specific toolchain. In case of GCC for ARC those functions rely on
LLOCK/SCOND instructions which are optional in ARC CPU's. If ARC CPU doesn't
support those instructions but software tries to use them, then application
will be aborted with Illegal instruction exception. To avoid confusion user
should first specify that their CPU supports atomic extension, which will
allow selection of packages that use builtin atomic functions.

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03 11:20:47 +02:00
Yann E. MORIN
a930d9cef6 toolchain: linker options with a $ sign are not supported
As reported in bug #7172 [0], setting BR2_TARGET_LDFLAGS to a value
containing a $ sign can lead to unexpected results.

This is because it is very hard to know when the $ sign gets evaluated:
  - in the Buildroot-level make
  - in the shell called by the Buildroot-level make
  - in the package's own build-system, either at configure time, in the
    Makefile, in a shell in the Makefile...

So, it is very difficult to know how much escaping that would need.

A proposal is to use a shell variable to pass such values unmolested.
But it is not that simple either, since it still contains a $ sign, and
there is not much certainty as to when it would be evaluated.

Instead, just document this limitation, both in the help text for
BR2_TARGET_LDFLAGS, and in the known-issues section in the manual.

Does not really fix #7172, but at least the limitation is documented.

[0] https://bugs.buildroot.org/show_bug.cgi?id=7172

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Mike Zick <minimod@morethan.org>
Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-07-31 23:51:39 +02:00
Yann E. MORIN
11c1076db9 toolchain: add option to copy the gconv libraries
The gconv libraries are used to translate between different character sets
('charsets', even 'csets' sometimes). Some packages need them to present
text to the user (eg. XBMC Gotham).

In (e)glibc they are implemented by the internal implemenation of iconv,
called gconv, and are provided as dlopen-able libraries.

Note that some gconv modules need extra libraries (shared by more than
one gconv module), so we must, when adding a subset of modules, scan the
installed modules in search of the missing libraries.

[Thomas: add general explanation in expunge-gconv-modules and fix
coding style.]

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Cc: Eric Limpens <limpens@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-07-27 23:15:48 +02:00
Gustavo Zacarias
fb29afe2aa toolchain: add 3.15 choice for headers
[Thomas: fix BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_15 to select
BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_14 and not itself.]

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-09 14:48:55 +02:00
Gustavo Zacarias
ff69b4a6e5 toolchain: remove nommu option for MIPS
MIPS nommu never took off, the only MIPS processors without MMU are
microcontrollers and the only uclinux effort for them has non-upstream
patches against very very old versions.
See http://www.xiptech.com/uclinuxformips.htm

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-08 16:53:15 +02:00
Thomas Petazzoni
be4f30a4ff toolchain: add option to declare toolchains affected by gcc PR 58595
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-14 22:37:48 +02:00
Gustavo Zacarias
4916b889e2 linux-headers: add 3.14, bump 3.{4, 10, 13}.x series
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-01 14:44:27 +02:00
Samuel Martin
a1a86ebfba liburcu: disable build with gcc-4.8.x on ARM
Because of a gcc bug [1], liburcu checks for compiler version [2] and
stops the build prematurely if gcc-4.8.[0-2] is detected for ARM.

However a bug fix exists [3] and may be backported by ARM toolchain
providers; that's what is done in Buildroot [4] or Linaro [5].

So, this change:
- add a patch in liburcu to allow build with ARM gcc-4.8.2;
- adds a new hidden symbol to reflect the toolchain status with regard
  to this bug [1];
- and controls liburcu visibility.

However, a limitation of this is when the user is using a custom
toolchain; that's why the bug details have been added in the liburcu
help message.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
[2] http://git.lttng.org/?p=userspace-rcu.git;a=commitdiff;h=4b79310
[3] http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=204665
[4] http://git.buildroot.net/buildroot/commit/?id=c443c2be1768ebbdcb76c55d0a08fd7c983488c8
[5] http://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.8/revision/122147

[Peter: hide normal toolchain comment if bug, add comment explaining issue if bug]
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-03-23 23:17:56 +01:00
Yann E. MORIN
a5a309642a toolchain/external: check kernel headers version for custom toolchain
Ensure the kernel headers version used in the custom external toolchain,
or the manually-specified kernel headers version, matches exactly the one
selected by the user.

We do not care about the patch-level, since headers are not supposed to
change between patchlevels. This applies only to kernels >= 3.0, but
those are actually the ones we do care about; we treat all 2.6.x kernels
as being a single version, since we do not support any 2.6 kernels for
packages with kernel-dependant features.

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>
2014-03-01 19:47:22 +01:00
Yann E. MORIN
b155f5a5ab toolchain/common: add minimum kernel headers options
We now have quite a few packages that depend on the kernel headers to be
at least a certain version. For example, dvb-apps requires at least the
3.3 kernel headers.

Add a set of options that packages can depend on, to check that the kernel
headers match their required version.

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>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-01 17:15:09 +01:00
Thomas Petazzoni
c64f948d2c toolchain: introduce a toolchain knob for NPTL
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>
2014-02-22 23:39:01 +01:00
Thomas Petazzoni
f742fe4407 toolchain-crosstool-ng: remove support
In order to avoid the work of converting the toolchain-crosstool-ng
logic to the package infrastructure, we remove it from Buildroot,
since it has been deprecated since quite some time.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-06 20:50:41 +02:00
Thomas Petazzoni
c5866be0ad toolchain: refactor Stack Smashing Protection support
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>
2013-09-15 23:02:57 +02:00
Thomas Petazzoni
9b3e72b4fd arch: Refactor BR2_SOFT_FLOAT into per-architecture options
As we are going to introduced a more advanced support of floating
point options for the ARM architecture, we need to adjust how the
soft-float option is handled. We replace the current hidden option
BR2_PREFER_SOFT_FLOAT option and the visible BR2_SOFT_FLOAT option by:

 * A global hidden BR2_SOFT_FLOAT option, defined in arch/Config.in,
   that tells whether the architecture-specific code is using software
   emulated floating point. This hidden option can be used throughout
   Buildroot to determine whether soft float is used or not.

 * Per-architecture visible BR2_<arch>_SOFT_FLOAT options, for the
   architecture for which it makes sense, which allows users to select
   soft float emulation when needed.

This change will allow each architecture to have a different way of
presenting its floating point capabilities.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-16 14:35:07 +02:00
Thomas Petazzoni
381616e77a Introduce BR2_TOOLCHAIN_USES_{UCLIBC, GLIBC}
Currently, when we need to do a conditional on the type of C library
used, we need to take into account the three toolchain backends. As we
are going to add eglibc support to the Buildroot toolchain backend, it
would become even uglier, so this patch introduces two new hidden
options: BR2_TOOLCHAIN_USES_UCLIBC and BR2_TOOLCHAIN_USES_GLIBC, that
exist regardless of the toolchain backend. The entire Buildroot code
base is converted to use those options.

Note that we have intentionally created only one option
(BR2_TOOLCHAIN_USES_GLIBC) for both glibc and eglibc, since they are
essentially the same, as far as Buildroot is concerned.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-07-04 09:08:42 +02:00
Thomas Petazzoni
a0b6faaab4 gdb: convert to the package infrastructure
This commit converts gdb to the package infrastructure, and therefore
moves it from toolchain/gdb to package/gdb.

The target package is now visible in "Package selection for the
target" => "Debugging, profiling and benchmark". The main option,
"gdb", forcefully selects the "gdbserver" sub-option by
default. Another sub-option, "full debugger" allows to install the
complete gdb on the target. When this option is enabled, then
"gdbserver" is no longer forcefully selected. This ensures that at
least gdbserver or the full debugger gets built/installed, so that the
package is not a no-op.

The host debugger is still enabled through a configuration option in
"Toolchain". It is now visible regardless of the toolchain type (it
used to be hidden for External Toolchains). The configuration options
relative to the host debugger are now in package/gdb/Config.in.host,
similar to how we have package/binutils/Config.in.host.

Since gdb is now a proper package, it is no longer allowed to 'select
BR2_PTHREADS_DEBUG' to ensure thread debugging is available when
needed. Instead, it now 'depends on
BR2_TOOLCHAIN_HAS_THREADS_DEBUG'. This option, in turn, is selected by
the different toolchain backends when appropriate. The
'BR2_TOOLCHAIN_HAS_THREADS_DEBUG_IF_NEEDED' option is removed, since
we no longer need to know when it is allowed to 'select
BR2_PTHREADS_DEBUG'. Also, the 'BR2_PTHREADS_DEBUG' option is moved to
appear right below the thread implementation selection (in the case of
the Buildroot toolchain backend).

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-04-11 21:46:32 +02:00
Thomas Petazzoni
217ef08a97 Integration with Buildroot Toolchain Eclipse plugin
The Eclipse plugin at
https://github.com/mbats/eclipse-buildroot-toolchain-plugin allows
users of Eclipse to easily use the toolchain available in
Buildroot. To do so, this plugin reads
~/.buildroot-eclipse.toolchains, which contains the list of Buildroot
toolchains available on the system, and then offer those toolchains to
compile Eclipse projects.

In order to interface with this plugin, this commit adds an option
that allows the user to tell whether (s)he wants the Buildroot project
toolchain to be visible under this Eclipse plugin. It simply adds a
line in this ~/.buildroot-eclipse.toolchains file.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-01-14 16:33:30 +01:00
Chris Zankel
75720db391 xtensa: add support for the Xtensa architecture
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>
2012-11-15 16:39:43 +01:00
Thomas Petazzoni
0858e000fe Rename BR2_INET_RPC to BR2_TOOLCHAIN_HAS_NATIVE_RPC
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>
2012-11-04 01:14:48 +01:00
Thomas Petazzoni
669d07bdd4 Remove the Xtensa architecture
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>
2012-09-20 22:31:08 +02:00
Thomas Petazzoni
f648ad2817 toolchain-external: do not allow the user to select hard/soft float
Commit ba92d6ef68 made hard float the
default when Cortex-A8 and Cortex-A9. The problem it was trying to fix
is that the newer Linaro toolchains (2012.05 and 2012.06) are
hard-float, so the default selection of soft-float enabled on ARM
doesn't work for those toolchains.

Unfortunately, not selecting soft-float causes problems with
the Crosstool-NG backend at the moment.

As an intermediate solution, make the soft float option disappear when
using external toolchain: the toolchain will decide by itself whether
to generate hard float or soft float code.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-08-01 20:04:50 +02:00
Thomas Petazzoni
ba92d6ef68 Make hard-float the default on Cortex-A8 and Cortex-A9
Cortex-A8 and Cortex-A9 ARM cores are guaranteed to provide a hardware
floating point unit, so there's no reason to default to software
floating point for them.

More importantly, the newest Linaro toolchains are hard float
toolchains, so basically an user choosing those toolchains and leaving
the default option of software float would run in compilation issues.

So let's make hard float the default for Cortex-A8 and Cortex-A9.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-07-22 16:53:52 +02:00
Thomas Petazzoni
aebf199ff0 Add support to generate locale data
In order to use locale support on a Linux system, you need locale data
to be present:

 * on a (e)glibc based system, this data is typically in the
   /usr/lib/locale/locale-archive file, which can be created and
   extended using the localedef program

 * on an uClibc based system, the set of supported locales is defined
   at build time by an uClibc configuration option.

This patch implements generating locale data for the following cases:

 * Internal toolchain

 * External toolchain based on (e)glibc. uClibc external toolchains
   are not supported, because with uClibc, the set of supported
   locales is defined at build time. CodeSourcery and Linaro
   toolchains have been tested, Crosstool-NG toolchains are believed
   to work properly as well.

 * Toolchains built using the Crosstool-NG backend, but only (e)glibc
   toolchains.

This feature was runtime tested with internal uClibc toolchain,
CodeSourcery ARM toolchain and Linaro ARM toolchain, thanks to a
simple C program that shows the data and a gettext translated message.

Note that this option differs from the "purge locales" option, which
is responsible for removing translation files and other locale stuff
installed by packages. At some point in the future, we may want to
clarify the respective roles of those options.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-05-09 00:26:21 +02:00
Thomas De Schampheleire
8f8d414b61 Fix typo buiding -> building
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-01-15 20:47:58 +01:00
Peter Korsgaard
5931db0de9 gdb: fix kconfig dependency handling with !BR_TOOLCHAIN_BUILDROOT
Newer versions of GDB need pthread debugging support if threads are
enabled, which is always the case for glibc but is a configure option
for uClibc.

We have solved this for internal toolchains by selecting the
BR2_PTHREAD_DEBUG option from the GDB selection if needed, but as this
option isn't available when ctng/external toolchains are used, mconf
prints ugly warnings and the build may fail if an external uClibc
toolchain without pthread debugging support is used.

Fix it by introducing 2 more hidden config options:
 - BR2_TOOLCHAIN_HAS_THREADS_DEBUG
 - BR2_TOOLCHAIN_HAS_THREADS_DEBUG_IF_NEEDED

The first tells us if the toolchain HAS pthreads debugging support,
and is checked by check_uclibc_feature in helper.mk for external uClibc
based toolchains.

The second tells us if the toolchain is ABLE TO provide pthreads debugging
support if threads are enabled, either because it's an internal toolchain
where we can force enable it or an external glibc/eglibc toolchain or
uClibc with the option enabled.

Crosstool-ng forcibly enables this support, so those will always work.
The preconfigured uClibc-based toolchains we have also all enable it.

Finally, show a comment if this isn't the case so the (external toolchain)
user knows why. This is placed outside the choice option, as menuconfig
has a bug where it doesn't show choice selections which only contain
comments.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-11-24 14:26:52 +01:00
Peter Korsgaard
4ee9d569f9 uClibc: drop BR2_PROGRAM_INVOCATION option
Remove the BR option and enable the configuration setting in the
uClibc defconfigs.

The BR2_PROGRAM_INVOCATION option only adds very little overhead to
uClibc, and we have a number of packages needing it, so simply always
enable it - Simplifying the kconfig logic and the number of choices
users have to make.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-07-27 11:56:53 +02:00
Baruch Siach
ec8eda419a toolchain: add user defined target LDFLAGS options
Allow the user to specify additional options for the target LDFLAGS.

I use this to pass the -te500v2 option to the linker, when using the
CodeSourcery toolchain for PowerPC. This chooses the correct CRT for e500 hard
float. Otherwise I get errors like

undefined reference to `_save32gpr_31'
undefined reference to `_rest32gpr_31_x'

at final link time.

[Peter: fixup, use qstrip]
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-07-25 08:31:15 +02:00
Thomas Petazzoni
b9882925a4 toolchain: introduce BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS
Unfortunately, the official Blackfin toolchains are built without the
shadow password support, so our default Busybox configuration fails to
build.

Therefore, we introduce a new hidden knob
BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS, which is set to yes for Buildroot
internal toolchain, for toolchains generated by the Crosstool-NG
backend, for Glibc external toolchains and for Uclibc custom external
toolchains. It is left unset by the Blackfin toolchain profile.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-06-12 21:50:20 +02:00
Mike Frysinger
871db074b1 initial support for Blackfin processors
[Peter: don't allow MMU on bfin]
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-02-07 14:29:19 +01:00