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

100 lines
3.1 KiB
Plaintext
Raw Normal View History

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
# Config entries for internal toolchain backend
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
Use BR2_TOOLCHAIN_BUILDROOT instead of BR2_TOOLCHAIN_SOURCE The BR2_TOOLCHAIN_SOURCE option is removed in a future commit. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2009-12-14 12:10:12 +01:00
if BR2_TOOLCHAIN_BUILDROOT
toolchain: control vendor part in GNU_TARGET_NAME This option allows to customize the "vendor" part of the toolchain tuple, where the toolchain tuple has the form <arch>-<vendor>-<os>-<libc>. Use this option in situations where gcc might make different decisions based on the vendor part of the tuple. [Thomas: move the config option in a slightly different place, so that it does not appear between the C library selection and the C library options.] Signed-off-by: "Noam Camus" <noamc@ezchip.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-01 08:25:47 +02:00
toolchain: configs: improve toolchain config readability Add (or move) comment lines in toolchain-related Config.in files to improve readability of the toolchain config section. Source linux-headers/Config.in.host after toolchain-buildroot items. For toolchain-buildroot case, the config file now looks like this: * * Toolchain * * * Toolchain Buildroot Options * * * Kernel Header Options * * * uClibc Options * * * Binutils Options * * * GCC Options * * * Host GDB Options * * * Toolchain Generic Options * Signed-off-by: Petri Gynther <pgynther@google.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-08 20:34:59 +02:00
comment "Toolchain Buildroot Options"
toolchain: control vendor part in GNU_TARGET_NAME This option allows to customize the "vendor" part of the toolchain tuple, where the toolchain tuple has the form <arch>-<vendor>-<os>-<libc>. Use this option in situations where gcc might make different decisions based on the vendor part of the tuple. [Thomas: move the config option in a slightly different place, so that it does not appear between the C library selection and the C library options.] Signed-off-by: "Noam Camus" <noamc@ezchip.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-01 08:25:47 +02:00
config BR2_TOOLCHAIN_BUILDROOT_VENDOR
string "custom toolchain vendor name"
default "buildroot"
help
This option allows to customize the "vendor" part of the
toolchain tuple, where the toolchain tuple has the form
<arch>-<vendor>-<os>-<libc>. The default value, "buildroot",
is fine for most cases, except in very specific situations
where gcc might make different decisions based on the vendor
part of the tuple. The value "unknown" is not allowed, as the
cross-compiling toolchain might then be confused with the
native toolchain when the target and host architecture are
identical. The value can not be empty either.
If you're not sure, just leave the default "buildroot" value.
eglibc: enable support in the Buildroot toolchain backend 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>
2013-06-30 21:29:12 +02:00
choice
prompt "C library"
toolchain/buildroot: fix default of C library choice The BR2_TOOLCHAIN_UCLIBC symbol doesn't exist, it was meant to be BR2_TOOLCHAIN_BUILDROOT_UCLIBC. Signed-off-by: Petr Vorel <petr.vorel@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-05-09 18:33:22 +02:00
default BR2_TOOLCHAIN_BUILDROOT_UCLIBC
uclibc: allow to build aarch64 internal toolchain uClibc-ng from 1.0.22 and up supports aarch64 architecture. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-02-03 15:28:14 +01:00
default BR2_TOOLCHAIN_BUILDROOT_GLIBC if BR2_powerpc64
eglibc: enable support in the Buildroot toolchain backend 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>
2013-06-30 21:29:12 +02:00
config BR2_TOOLCHAIN_BUILDROOT_UCLIBC
uclibc: the internal toolchain only uses uClibc-ng Point to the right website and tell the user the right name. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-04 22:53:47 +02:00
bool "uClibc-ng"
package/uclibc: introduce and use BR2_PACKAGE_UCLIBC_ARCH_SUPPORTS and BR2_PACKAGE_UCLIBC_SUPPORTS In this commit BR2_PACKAGE_UCLIBC_SUPPORTS looks redundant with BR2_PACKAGE_UCLIBC_ARCH_SUPPORTS, but for other C libraries, like glibc, it can be different. To be consistent, we use the same pattern for uClibc. Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-06-05 21:42:53 +02:00
depends on BR2_PACKAGE_UCLIBC_SUPPORTS
toolchain/*/Config.in: fix attributes order ... to follow the convention: type, default, depends on, select, help. Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-04-01 07:08:38 +02:00
select BR2_TOOLCHAIN_USES_UCLIBC
eglibc: enable support in the Buildroot toolchain backend 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>
2013-06-30 21:29:12 +02:00
help
uclibc: the internal toolchain only uses uClibc-ng Point to the right website and tell the user the right name. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-04 22:53:47 +02:00
This option selects uClibc-ng as the C library for the
eglibc: enable support in the Buildroot toolchain backend 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>
2013-06-30 21:29:12 +02:00
cross-compilation toolchain.
uclibc: the internal toolchain only uses uClibc-ng Point to the right website and tell the user the right name. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-04 22:53:47 +02:00
http://uclibc-ng.org
eglibc: enable support in the Buildroot toolchain backend 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>
2013-06-30 21:29:12 +02:00
toolchain: add support for glibc The support for eglibc 2.17 was added to the internal toolchain backend for 2013.08. This commit now adds glibc 2.18 support to the internal toolchain backend. Since the building procedure is very similar to the one of eglibc, we have renamed the 'eglibc' package to 'glibc', and made it capable of handling either glibc or eglibc. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-09-02 18:06:33 +02:00
config BR2_TOOLCHAIN_BUILDROOT_GLIBC
toolchain-buildroot: glibc and eglibc support is no longer experimental The glibc and eglibc support has been introduced since a little bit of time now, I believe we can remove the "experimental" statement next to it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-11-11 18:57:30 +01:00
bool "glibc"
package/glibc: introduce and use BR2_PACKAGE_GLIBC_ARCH_SUPPORTS and BR2_PACKAGE_GLIBC_SUPPORTS As part of this, the dependency of the comment "glibc needs a toolchain w/ dynamic library, kernel headers >= 3.2" is changed to use BR2_PACKAGE_GLIBC_ARCH_SUPPORTS instead of just BR2_USE_MMU, so that the comment only appears on architectures for which glibc is supported Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-06-05 21:42:54 +02:00
depends on BR2_PACKAGE_GLIBC_SUPPORTS
glibc: needs MMU Like eglibc, glibc is only available to MMU-based architectures. Re-order select/depends to be in-line with eglibc, just above. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-03 19:31:27 +01:00
select BR2_TOOLCHAIN_USES_GLIBC
toolchain: add support for glibc The support for eglibc 2.17 was added to the internal toolchain backend for 2013.08. This commit now adds glibc 2.18 support to the internal toolchain backend. Since the building procedure is very similar to the one of eglibc, we have renamed the 'eglibc' package to 'glibc', and made it capable of handling either glibc or eglibc. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-09-02 18:06:33 +02:00
help
This option selects glibc as the C library for the
cross-compilation toolchain.
http://www.gnu.org/software/libc/
toolchain: invert glibc <-> !static dependency Currently, glibc depends on !BR2_STATIC_LIBS in all the toolchain variants. However, for some architectures, glibc is the only supported libc. In commit 3b3105328e4aa54f3cfecbf8454a9db63875d76e ("Config.in: only allow BR2_STATIC_LIBS on supported libc/arch"), we implemented a fix to avoid configurations were BR2_STATIC_LIBS=y with an architecture already supported by glibc, because these configurations are impossible. This commit 3b3105328e4aa54f3cfecbf8454a9db63875d76e prevents from selecting BR2_STATIC_LIBS=y when the C library used for the internal toolchain backend is glibc. However, it introduces a discrepency between how this topic is handled for internal and external toolchains: - For internal toolchains, we prevent BR2_STATIC_LIBS=y if glibc is chosen. - For external toolchains, we allow BR2_STATIC_LIBS=y in all cases, and it's each glibc toolchain that has !BR2_STATIC_LIBS This commit addresses this discrepency by preventing BR2_STATIC_LIBS=y if glibc is chosen in all cases. Thanks to this, we can remove the !BR2_STATIC_LIBS dependency on both the glibc package, and all glibc external toolchains. Fixes: https://bugs.busybox.net/show_bug.cgi?id=14256 Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Thomas: update to master, fix the gen-bootlin-toolchains script, add a comment in the static/shared choice to indicate that static is supported only with uclibc or musl] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-10-06 22:41:32 +02:00
comment "glibc needs a toolchain w/ kernel headers >= 3.2"
package/glibc: introduce and use BR2_PACKAGE_GLIBC_ARCH_SUPPORTS and BR2_PACKAGE_GLIBC_SUPPORTS As part of this, the dependency of the comment "glibc needs a toolchain w/ dynamic library, kernel headers >= 3.2" is changed to use BR2_PACKAGE_GLIBC_ARCH_SUPPORTS instead of just BR2_USE_MMU, so that the comment only appears on architectures for which glibc is supported Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-06-05 21:42:54 +02:00
depends on BR2_PACKAGE_GLIBC_ARCH_SUPPORTS
toolchain: invert glibc <-> !static dependency Currently, glibc depends on !BR2_STATIC_LIBS in all the toolchain variants. However, for some architectures, glibc is the only supported libc. In commit 3b3105328e4aa54f3cfecbf8454a9db63875d76e ("Config.in: only allow BR2_STATIC_LIBS on supported libc/arch"), we implemented a fix to avoid configurations were BR2_STATIC_LIBS=y with an architecture already supported by glibc, because these configurations are impossible. This commit 3b3105328e4aa54f3cfecbf8454a9db63875d76e prevents from selecting BR2_STATIC_LIBS=y when the C library used for the internal toolchain backend is glibc. However, it introduces a discrepency between how this topic is handled for internal and external toolchains: - For internal toolchains, we prevent BR2_STATIC_LIBS=y if glibc is chosen. - For external toolchains, we allow BR2_STATIC_LIBS=y in all cases, and it's each glibc toolchain that has !BR2_STATIC_LIBS This commit addresses this discrepency by preventing BR2_STATIC_LIBS=y if glibc is chosen in all cases. Thanks to this, we can remove the !BR2_STATIC_LIBS dependency on both the glibc package, and all glibc external toolchains. Fixes: https://bugs.busybox.net/show_bug.cgi?id=14256 Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Thomas: update to master, fix the gen-bootlin-toolchains script, add a comment in the static/shared choice to indicate that static is supported only with uclibc or musl] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-10-06 22:41:32 +02:00
depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2
toolchain-buildroot: make sure glibc isn't chosen when BR2_PREFER_STATIC_LIB=y (e)glibc doesn't support a fully statically linked userspace. Even a basic program such as Busybox fails to do authentication due to glibc loading some libraries dynamically. Therefore, we disable the possibility of building a glibc toolchain when BR2_PREFER_STATIC_LIB=y. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-11-11 18:57:31 +01:00
package/glibc: needs kernel headers >= 3.10 on powerpc64le Since glibc 2.26, kernel headers >= 3.10 are needed on powerpc64le [1]. In order to prepare the glibc bump to this version, we don't allow to build a Buildroot toolchain with kernel headers older than 3.10. [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=c2ff5ec13fca1bdd1cd646a0260808386d7bd7ff Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2017-09-23 23:24:02 +02:00
# glibc >= 2.26 require kernel headers >= 3.10 on powerpc64le.
comment "glibc on powerpc64le needs a toolchain w/ headers >= 3.10"
depends on BR2_powerpc64le
depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_10
toolchain/buildroot: add comment for glibc NaN-2008 headers requirement Commit 4a5140ecf (toolchain/buildroot: glibc requires kernel headers >= 4.5 with NaN-2008) added a restriction on kernel headers for glibc when the architecture is using naN-2008. However, such a restriction is usually associated to a comment explaining the restriction, so the user knows what is happening. That comment was forgotten in 4a5140ecf. Add it now. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-11-25 16:19:02 +01:00
# Support for MIPS NAN2008 needs headers >= 4.5
comment "glibc on MIPS w/ NAN2008 needs a toolchain w/ headers >= 4.5"
depends on BR2_MIPS_NAN_2008
depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_5
toolchain/toolchain-buildroot, package/glibc: sync glibc dependency comments In commit fd839aeb7f40596e60bc53a96b7a65892924cc26 ("package/glibc: introduce and use BR2_PACKAGE_GLIBC_ARCH_SUPPORTS and BR2_PACKAGE_GLIBC_SUPPORTS") we moved the Config.in logic about glibc dependencies from toolchain/toolchain-buildroot/Config.in into package/glibc/Config.in. Unfortunately, it is not possible to move the Config.in comments that tell the user, within the choice..endchoice for the C library why glibc is not currently selectable, so we had to keep them in toolchain/toolchain-buildroot/Config.in. Turns out that the comments were out of sync with the dependencies, and two comments were missing. This commit adds the missing ones, and adds a comment in package/glibc/Config.in explaining that we need to be careful about updating toolchain/toolchain-buildroot/Config.in as well. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2022-07-26 15:42:02 +02:00
comment "glibc on RISC-V 64-bit needs a toolchain w/ headers >= 5.0"
depends on BR2_RISCV_64
depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_0
comment "glibc on ARC needs a toolchain w/ headers >= 5.1"
depends on BR2_arc
depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_1
package/glibc: glibc on or1k needs a toolchain w/ headers >= 5.4 Commit [1] enabled glibc on or1k since it's now supported but it requires a toolchain with linux-headers >= 5.4. From [2]: "Here we define the minumum linux kernel version at 5.4.0, as that is the long term support version where 32-bit architectures start to support 64-bit time API's. The OpenRISC kernel had some bugs up until version 5.8 which caused issues with glibc fork/clone, they have been backported to 5.4 but not previous versions." Fixes: checking installed Linux kernel header files... 3.2.0 or later checking for kernel header at least 5.4.0... too old! configure: error: *** The available kernel headers are older than the requested https://gitlab.com/buildroot.org/toolchains-builder/-/jobs/2875256686 [1] 68d0aede597d32816c5b2ff32de0ce33cc14eb93 [2] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=0c3c62ca7d9ff3bdacdd13e636bc858101e3e288 Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
2022-08-27 18:14:30 +02:00
comment "glibc on or1k needs a toolchain w/ headers >= 5.4"
depends on BR2_or1k
depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_4
toolchain-buildroot: add support for building musl toolchains Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-05 23:17:08 +02:00
config BR2_TOOLCHAIN_BUILDROOT_MUSL
toolchain: musl support is no longer experimental Our musl support has now been around for quite some time, numerous packages have been fixed (although admittedly not all). It's time to no longer call our musl support "experimental": things are now expected to be working with musl just like with the other two C libraries we support. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-05-17 00:13:02 +02:00
bool "musl"
package/musl: introduce and use BR2_PACKAGE_MUSL_ARCH_SUPPORTS and BR2_PACKAGE_MUSL_SUPPORTS In this commit BR2_PACKAGE_MUSL_SUPPORTS looks redundant with BR2_PACKAGE_MUSL_ARCH_SUPPORTS, but for other C libraries, like glibc, it can be different. To be consistent, we use the same pattern for musl. Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-06-05 21:42:55 +02:00
depends on BR2_PACKAGE_MUSL_SUPPORTS
toolchain-buildroot: add support for building musl toolchains Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-05 23:17:08 +02:00
select BR2_TOOLCHAIN_USES_MUSL
help
This option selects musl as the C library for the
cross-compilation toolchain.
package/musl: add an upstream URL to Config.in Add an upstream URL to the help text in Config.in. This addresses the 'Missing' URL status in the package stats web page output. [Peter: also add URL to BR2_TOOLCHAIN_BUILDROOT_MUSL help] Signed-off-by: Mark Corbin <mark@dibsco.co.uk> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-11-28 18:58:42 +01:00
https://www.musl-libc.org/
eglibc: enable support in the Buildroot toolchain backend 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>
2013-06-30 21:29:12 +02:00
endchoice
config BR2_TOOLCHAIN_BUILDROOT_LIBC
string
default "uclibc" if BR2_TOOLCHAIN_BUILDROOT_UCLIBC
toolchain: add support for glibc The support for eglibc 2.17 was added to the internal toolchain backend for 2013.08. This commit now adds glibc 2.18 support to the internal toolchain backend. Since the building procedure is very similar to the one of eglibc, we have renamed the 'eglibc' package to 'glibc', and made it capable of handling either glibc or eglibc. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-09-02 18:06:33 +02:00
default "glibc" if BR2_TOOLCHAIN_BUILDROOT_GLIBC
toolchain-buildroot: add support for building musl toolchains Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-05 23:17:08 +02:00
default "musl" if BR2_TOOLCHAIN_BUILDROOT_MUSL
eglibc: enable support in the Buildroot toolchain backend 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>
2013-06-30 21:29:12 +02:00
toolchain: configs: improve toolchain config readability Add (or move) comment lines in toolchain-related Config.in files to improve readability of the toolchain config section. Source linux-headers/Config.in.host after toolchain-buildroot items. For toolchain-buildroot case, the config file now looks like this: * * Toolchain * * * Toolchain Buildroot Options * * * Kernel Header Options * * * uClibc Options * * * Binutils Options * * * GCC Options * * * Host GDB Options * * * Toolchain Generic Options * Signed-off-by: Petri Gynther <pgynther@google.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-08 20:34:59 +02:00
source "package/linux-headers/Config.in.host"
package/c-libraries: need linux-headers Now that we check that a target package in the _DEPENDENCIES of another package has to be enabled in config, all target packages must have a kconfig symbol. Add a Kconfig symbol for linux-headers, and select it from the packages that depends on it (C libraries). Also remove the now-misleading comments "for legal-info" from the C libraries. Fixes: http://autobuild.buildroot.org/results/2a9/2a9e5d27b34357819b44f573a834da1ba5079030/ ... and numerous similar failures ... 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>
2015-12-30 00:10:38 +01:00
source "package/linux-headers/Config.in"
toolchain: also source the musl package We do source the glibc and uClibc packages in the toolchain menu, because they do provide user-visible options. However, we do not so far source the musl Config.in file However, in 822be87 (toolchain: include C libraries in legal-info), a Config.in file for musl was explicitly created, so that: - legal-info would work (needed at the time, probably no longer needed nowadays), - the appropriate packages are enabled, like netbsd-queue or kernel headers. Yet, we do not source musl/Config.in, which means we do not get netbsd-queue or kernel-headers to be selected: $ make distclean; make menuconfig Toolchain ---> C library ---> musl save-and-exit $ grep BR2_PACKAGE_LINUX_HEADERS .config [nothing] $ grep BR2_PACKAGE_NETBSD_QUEUE .config [nothing] Fix that by sourcing musl/Config.in at the same place we source glibc and uClibc. Normally, we do have a check in place that verifies that a package that is not enabled is not a dependency of another package that is enabled. However, musl is only a dependency of host-gcc-final, which is a host package and has no corresponding BR2_PACKAGE_HOST_GCC_FINAL. Thus host-gcc-final is not in the PACKAGES variable, and thus does not trigger our check. Reported-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-08 21:02:22 +01:00
source "package/musl/Config.in"
uclibc: convert to the package infrastructure [Peter: update manual to match] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-06-30 21:29:05 +02:00
source "package/uclibc/Config.in"
glibc: add 2.19 as a supported version glibc 2.19 has been released recently (https://sourceware.org/ml/libc-alpha/2014-02/msg00224.html). This commit allows to build a toolchain with this new version. In order to allow this, we add a version selection that did not exist for glibc. We default to 2.18, which was the only supported version until now, and add an option for 2.19. For microblaze, which uses a specific glibc version, the version selection choice is not displayed. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-02-10 18:43:46 +01:00
source "package/glibc/Config.in"
binutils: make it a proper package * Convert binutils to a proper autotargets package * Add version 2.21 and drop version 2.17 * Hook up packaged binutils for target gcc * Build tools are on HOST_DIR now so change it * Move cross/host gcc to HOST_DIR * Drop kludge from commit 3c77bab2eeace3ee675bd745ca335fa3dd1630bb This is fixed in the next commit "gcc: install copies of libgcc, libstdc++ and libgcj to the sysroot" - tested for arm & x86_64 targets. * TARGET_CROSS now pointed to HOST_DIR too [Peter: Config.in tweaks] Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-12-31 12:39:01 +01:00
source "package/binutils/Config.in.host"
toolchain: switch to using gcc through package infrastructure Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-06-30 21:29:03 +02:00
source "package/gcc/Config.in.host"
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
endif
Reference in New Issue Copy Permalink