NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
69f1de8ca3
kumquat-buildroot/toolchain/Config.in

66 lines
1.6 KiB
Plaintext
Raw Normal View History

- Subsume and collaps toolchain options in one menu This is ment to ease configuration by providing toolchain related options in one place No functional changes, just shuffling the menus around..
2007-09-22 16:16:25 +02:00
menu "Toolchain"
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-06-30 21:29:09 +02:00
toolchain: add a hidden config option to enable the toolchain package The usual way to enable a package using the package infrastructure is to use a config option so instead to add the toolchain package to the TARGETS variable in the Makefile add a config option like all the other toolchain packages. [Thomas: remove comment that no longer made sense in the main Makefile, and add a comment above the new hidden Config.in option to explain what it is useful for.] Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-07 11:56:48 +02:00
# Invisible option that makes sure the toolchain package always gets
# built
config BR2_TOOLCHAIN
bool
default y
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-06-30 21:29:09 +02:00
# Should be selected for glibc or eglibc
config BR2_TOOLCHAIN_USES_GLIBC
bool
select BR2_USE_WCHAR
select BR2_ENABLE_LOCALE
toolchain: introduce BR2_TOOLCHAIN_HAS_FULL_GETTEXT This new boolean is true if the toolchain provides a built-in full-featured implementation of gettext (glibc), and false if only a stub implementation is provided (uclibc, musl). This will be used in follow-up commits to decide whether libintl needs to be built by gettext or not. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-04 16:47:46 +02:00
select BR2_TOOLCHAIN_HAS_FULL_GETTEXT
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-06-30 21:29:09 +02:00
select BR2_TOOLCHAIN_HAS_THREADS
select BR2_TOOLCHAIN_HAS_THREADS_DEBUG
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-18 22:08:59 +01:00
select BR2_TOOLCHAIN_HAS_THREADS_NPTL
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-06-30 21:29:09 +02:00
select BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS
toolchain: add hidden symbol for PIE support uClibc-ng does not support PIE for some architectures as arc and m68k. It isn't implemented in the static linking case, too. With musl toolchains you might have static PIE support with little patching of gcc. Static linking for GNU libc isn't enabled in buildroot. Fixup any package using special treatment of PIE. (grep -ir pie package/*/*.mk) Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> [Thomas: use positive logic.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-11 16:35:14 +02:00
select BR2_TOOLCHAIN_SUPPORTS_PIE
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-06-30 21:29:09 +02:00
config BR2_TOOLCHAIN_USES_UCLIBC
bool
uclibc: disable PIE for microblaze PIE is not supported at the moment for uClibc-ng/microblaze. Fixes: http://autobuild.buildroot.net/results/a5848753eb0e2b0ddf55e226c45b85fd3a1c84f3/ Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-31 23:41:26 +02:00
select BR2_TOOLCHAIN_SUPPORTS_PIE if !BR2_m68k && !BR2_microblaze && !BR2_STATIC_LIBS
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-06-30 21:29:09 +02:00
toolchain-external: add support for musl C library This commit adds support for external toolchains based on the musl C library, as available from http://www.musl-libc.org. Note that the pre-built musl toolchains available from http://musl.codu.org/ are not working for the moment, since they lack sysroot support. However, this problem has been reported to the maintainer, who has already added sysroot support in his scripts at https://bitbucket.org/GregorR/musl-cross, and therefore the next version of the pre-built toolchains should work with Buildroot out-of-the-box. In the mean time, the musl-cross script must be used to build the toolchain. [Peter: reword comment] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-08 20:17:09 +02:00
config BR2_TOOLCHAIN_USES_MUSL
bool
select BR2_USE_WCHAR
select BR2_ENABLE_LOCALE
select BR2_TOOLCHAIN_HAS_THREADS
select BR2_TOOLCHAIN_HAS_THREADS_DEBUG
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-18 22:08:59 +01:00
select BR2_TOOLCHAIN_HAS_THREADS_NPTL
toolchain: disable PIE for static build with musl As mentioned in commit 3c93901bcd2 (toolchain: add hidden symbol for PIE support), support for static PIE using musl requires a gcc patch[1]. Buildroot doesn't carry this patch. Don't enable BR2_TOOLCHAIN_SUPPORTS_PIE in static build with musl. Fixes: http://autobuild.buildroot.net/results/d19/d19bcfcfb33cc5f5b082b97bbd5852d479823b97/ http://autobuild.buildroot.net/results/91f/91f7c6954c337b03f5ac141050d9b1bee1623376/ http://autobuild.buildroot.net/results/996/996116da9241686110b9525eed08cc5acfd379a6/ [1] https://github.com/richfelker/musl-cross-make/blob/b854a42fc1ea19b8c4ec7104848f9d1a6d7995f0/patches/gcc-6.3.0/0010-static-pie-support.diff Acked-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-05-23 00:07:09 +02:00
select BR2_TOOLCHAIN_SUPPORTS_PIE if !BR2_STATIC_LIBS
toolchain-external: add support for musl C library This commit adds support for external toolchains based on the musl C library, as available from http://www.musl-libc.org. Note that the pre-built musl toolchains available from http://musl.codu.org/ are not working for the moment, since they lack sysroot support. However, this problem has been reported to the maintainer, who has already added sysroot support in his scripts at https://bitbucket.org/GregorR/musl-cross, and therefore the next version of the pre-built toolchains should work with Buildroot out-of-the-box. In the mean time, the musl-cross script must be used to build the toolchain. [Peter: reword comment] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-08 20:17:09 +02:00
Support building using an external toolchain. Questions to the mailing list and all other comments to <biteme@devnull.com>.
2007-02-06 19:19:38 +01:00
choice
prompt "Toolchain type"
Add BR2_CROSS_TOOLCHAIN_TARGET_UTILS to allow bundling of some useful debug apps with a deployed cross toolchain. Should probably do ltrace as well... Also, add another compat symlink for cross gdb.
2005-08-04 05:49:25 +02:00
help
- revert some bad checkins, fixup bad settings in atmel targets and move the gcc target abi back to a place where the other arch-specific settings live
2007-09-26 23:12:38 +02:00
Select whether to use the toolchain provided by buildroot
or an external toolchain.
Some vendors provide toolchains in binary form, some in
source form.
- add more help text
2007-09-26 00:03:18 +02:00
Support building using an external toolchain. Questions to the mailing list and all other comments to <biteme@devnull.com>.
2007-02-06 19:19:38 +01:00
config BR2_TOOLCHAIN_BUILDROOT
- Subsume and collaps toolchain options in one menu This is ment to ease configuration by providing toolchain related options in one place No functional changes, just shuffling the menus around..
2007-09-22 16:16:25 +02:00
bool "Buildroot toolchain"
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-05-30 23:56:57 +02:00
select BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS
bfin: change default to bf532, internal toolchain !bf6xx The default Blackfin processor in Buildroot isn't supported by gcc 6.1.0, so use bf532 as default. Disable any bf6xx processors for internal toolchain users. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-07 00:30:15 +02:00
depends on !BR2_bf606
depends on !BR2_bf607
depends on !BR2_bf608
depends on !BR2_bf609
arch: add support for the csky architecture This commit provides basic support for the C-SKY architecture. Signed-off-by: Guo Ren <ren_guo@c-sky.com> [Thomas: minor tweaks.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-03-03 02:20:20 +01:00
depends on !BR2_csky
buildroot: remove trailing spaces for i in `find -name 'Config*' -o -name 'Makefile*' -o -name '*.mk'`; do sed -i 's/ \+$//' $i; done
2008-08-04 21:07:05 +02:00
Support building using an external toolchain. Questions to the mailing list and all other comments to <biteme@devnull.com>.
2007-02-06 19:19:38 +01:00
config BR2_TOOLCHAIN_EXTERNAL
toolchain: get rid of "binary" for external toolchain We no longer have an option for external source based toolchains, so get rid of "binary". Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-02-08 11:01:04 +01:00
bool "External toolchain"
toolchain: add support for external toolchain profiles and download Instead of letting the user define all the details of his external toolchain, we define a set of profiles for well-known external toolchains (CodeSourcery ones only at the moment, can easily be extended with other toolchains). Once a profile has been choosen, the user is offered the choice of either letting Buildroot download and install the external toolchain, or (as before) to tell Buildroot where the toolchain is installed on the system. We of course provide a "custom profile", through which the user can configure Buildroot to use a custom external toolchain for which no profile is available. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-12-13 17:27:39 +01:00
help
Select if you want to use an existing cross-compiling
toolchain. Buildroot can either download automatically a
toolchain, or use an already installed toolchain.
- revert some bad checkins, fixup bad settings in atmel targets and move the gcc target abi back to a place where the other arch-specific settings live
2007-09-26 23:12:38 +02:00
Support building using an external toolchain. Questions to the mailing list and all other comments to <biteme@devnull.com>.
2007-02-06 19:19:38 +01:00
endchoice
Major buildroot facelift, step one. -Erik
2004-10-09 03:06:03 +02:00
toolchain: move buildroot config files 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>
2010-07-28 00:08:16 +02:00
source "toolchain/toolchain-buildroot/Config.in"
toolchain: rename external toolchain dir Rename the external toolchain directory. When new backends are here, it will be easier to sort them out if they are all prefixed the same way. Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-07-28 00:08:14 +02:00
source "toolchain/toolchain-external/Config.in"
toolchain: move buildroot config files 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>
2010-07-28 00:08:16 +02:00
source "toolchain/toolchain-common.in"
toolchain: use same gdb Config.in for internal/external toolchains We used to use different gdb configs for internal and external toolchains because mconf won't source the same file twice. This works, but is kind of sub optimal, as people forget to keep them in sync. Fix it to use the same file for both situations by shuffling around the config options a bit. Should work identical to before (except for the newer gdb versions available for ext).
2008-12-15 16:28:48 +01:00
- Subsume and collaps toolchain options in one menu This is ment to ease configuration by providing toolchain related options in one place No functional changes, just shuffling the menus around..
2007-09-22 16:16:25 +02:00
endmenu
Reference in New Issue Copy Permalink