summaryrefslogtreecommitdiffstats
path: root/toolchain/toolchain-common.in
Commit message (Collapse)AuthorAgeFilesLines
* Introduce BR2_TOOLCHAIN_USES_{UCLIBC, GLIBC}Thomas Petazzoni2013-07-041-6/+2
| | | | | | | | | | | | | | | | | 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>
* gdb: convert to the package infrastructureThomas Petazzoni2013-04-111-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Integration with Buildroot Toolchain Eclipse pluginThomas Petazzoni2013-01-141-0/+7
| | | | | | | | | | | | | | | | | | 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>
* xtensa: add support for the Xtensa architectureChris Zankel2012-11-151-1/+1
| | | | | | | | | | | | | 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>
* Rename BR2_INET_RPC to BR2_TOOLCHAIN_HAS_NATIVE_RPCThomas Petazzoni2012-11-041-1/+1
| | | | | | | | | | 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>
* Remove the Xtensa architectureThomas Petazzoni2012-09-201-1/+1
| | | | | | | | | | | | | | As stated in commit 555c2585bf28c3ef71f6d2dcdd983d17a19892af, 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>
* toolchain-external: do not allow the user to select hard/soft floatThomas Petazzoni2012-08-011-1/+4
| | | | | | | | | | | | | | | | | Commit ba92d6ef68eeb37ba435648fcfbd1dbe13212e6d 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>
* Make hard-float the default on Cortex-A8 and Cortex-A9Thomas Petazzoni2012-07-221-1/+5
| | | | | | | | | | | | | | 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>
* Add support to generate locale dataThomas Petazzoni2012-05-091-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix typo buiding -> buildingThomas De Schampheleire2012-01-151-1/+1
| | | | | Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* gdb: fix kconfig dependency handling with !BR_TOOLCHAIN_BUILDROOTPeter Korsgaard2011-11-241-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* uClibc: drop BR2_PROGRAM_INVOCATION optionPeter Korsgaard2011-07-271-3/+0
| | | | | | | | | | | | 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>
* toolchain: add user defined target LDFLAGS optionsBaruch Siach2011-07-251-0/+5
| | | | | | | | | | | | | | | | | 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>
* toolchain: introduce BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDSThomas Petazzoni2011-06-121-0/+3
| | | | | | | | | | | | | | | 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>
* initial support for Blackfin processorsMike Frysinger2011-02-071-1/+1
| | | | | | | [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>
* toolchain-common.in: Fix USE_MMU typoPeter Korsgaard2011-01-151-1/+1
| | | | | | Thanks to Marc Gauthier for noticing. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: add a USE_MMU build optionMike Frysinger2011-01-151-0/+7
| | | | | | | | | | Some packages need to know whether the MMU is in play, so add a toolchain option to expose the feature to them. [Peter: only show option on archs where it makes sense] 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>
* toolchain: BR2_NEEDS_GETTEXT must be y when uClibc is usedThomas Petazzoni2010-12-131-0/+1
| | | | | | | | | BR2_NEEDS_GETTEXT was already set to y for Buildroot internal toolchain and external toolchains based on uClibc, but wasn't set for toolchains based on uClibC built by the Crosstool-NG backend. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: rework thread optionsThomas Petazzoni2010-12-131-26/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | The selection of linuxthreads, linuxthreads old or NPTL doesn't make a lot of sense for external toolchains. So, instead, we : * Introduce an hidden BR2_TOOLCHAIN_HAS_THREADS option, which must be selected by toolchain specific options when thread support is available. Package needing to test thread support should use this option. * Move the none/linuxthreads/linuxthreads old/NPTL selection to Buildroot internal toolchain configuration. * Add an option in external toolchain to tell if thread support is available or not in the external toolchain. We assume that glibc without threads is not possible, as Ulrich Drepper said in http://sourceware.org/ml/libc-alpha/2005-08/msg00091.html ffmpeg, dmalloc and openvpn are fixed to use the new BR2_TOOLCHAIN_HAS_THREADS option. For openvpn, --enable-threads=posix is no longer used, as the configure script doesn't even understand this option. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: move Stack Protection Support optionThomas Petazzoni2010-12-131-9/+0
| | | | | | | | | | The BR2_USE_SSP option is only used inside the uClibc build, so only meaningful for Buildroot internal toolchains. Therefore, the option is moved to the right location so that it isn't visible when working with external toolchains. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: rework C++ optionsThomas Petazzoni2010-12-131-22/+3
| | | | | | | | | | | | | | | | | | | | | | | | Instead of having BR2_GCC_CROSS_CXX and BR2_INSTALL_LIBSTDCPP, with BR2_GCC_CROSS_CXX not being visible (and therefore being useless), let's just keep BR2_INSTALL_LIBSTDCPP to enable C++ in the toolchain and install C++ libraries on the target. We also take that opportunity to make BR2_INSTALL_LIBSTDCPP an hidden option, which is selected by an option in Buildroot toolchain support or an option in External toolchain support, just as we did for other toolchain features. Some work definitely remains to be done : - The name BR2_INSTALL_LIBSTDCPP is ugly, but we keep it for the moment in order to avoid changing all packages. - We should clarify the other language-related options (Fortran, Java, Objective-C, etc.). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: Improve C library option selectionThomas Petazzoni2010-12-131-47/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Turn BR2_LARGEFILE, BR2_INET_IPV6, BR2_INET_RPC, BR2_USE_WCHAR, BR2_ENABLE_LOCALE and BR2_PROGRAM_INVOCATION into hidden options. Then, for Buildroot toolchains, external toolchains and Crosstool-NG toolchains, provide visible options that selects the hidden options. This allows : * To show a different label and help text in the case of Buildroot toolchain (do you want to enable feature X ?) and in the case of external toolchain (is feature X available in your toolchain ?) * To not show any option when a glibc external toolchain is selected (since glibc is assumed to support all of largefile, IPv6, RPC, WCHAR, locale and program invocation) and have them all selected in that case. There is some amount of duplication between Buildroot toolchain config options and Crosstool-NG toolchain config options, because kconfig doesn't allow to source the same Config.in file twice (even if under mutually exclusive conditions). This duplication is more readable that the hack that consists in splitting files in multiple pieces. However, this commit changes the name of the options visible in the configuration interface, so existing .config files will have to be updated accordingly. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Remove code specific to removed architecturesThomas Petazzoni2010-08-311-1/+0
| | | | Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Prevent C++ + locale + uClibc 0.9.31 + gcc 4.2 to be selectedThomas Petazzoni2010-08-111-3/+3
| | | | | | | | | The problem fixed by 60f945e47a15e10f0e777f69b05492b6f7ba918d is in fact not limited to the AVR32 architecture, as reported by Will Newton on the list. The issue is the combination uClibc 0.9.31 with gcc 4.2, C++ support and locales. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: mark uClibc 0.9.31 + locale + C++ as brokenThomas Petazzoni2010-07-291-0/+4
| | | | | | | | | | | | | | | It fails to build with: ctype_members.cc: In constructor 'std::ctype_byname<_CharT>::ctype_byname(const char*, size_t) [with _CharT = char]': ctype_members.cc:59: error: invalid use of incomplete type 'struct __uclibc_locale_struct' /home/test/avr32-br/usr/avr32-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85: error: forward declaration of 'struct __uclibc_locale_struct' ctype_members.cc:60: error: invalid use of incomplete type 'struct __uclibc_locale_struct' /home/test/avr32-br/usr/avr32-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85: error: forward declaration of 'struct __uclibc_locale_struct' ctype_members.cc:61: error: invalid use of incomplete type 'struct __uclibc_locale_struct' /home/test/avr32-br/usr/avr32-unknown-linux-uclibc/sys-include/bits/uClibc_locale.h:85: error: forward declaration of 'struct __uclibc_locale_struct' make[5]: *** [ctype_members.lo] Error 1 Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: move buildroot config filesYann E. MORIN2010-07-281-0/+172
Handle the internal toolchain backend mechanism the same way we handle other backends. Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-03 13:29:33 +0000