deepcrayon/buildroot
deepcrayon/buildroot
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity
buildroot/toolchain/toolchain-buildroot/Config.in

118 lines
4.4 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-27 16:08:16 -06: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 08:28:48 -07: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 04:10:12 -07: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 00:25:47 -06: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 12:34:59 -06: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 00:25:47 -06: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 13:29:12 -06: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 10:33:22 -06: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 07:28:14 -07: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 13:29:12 -06: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 14:53:47 -06:00
bool "uClibc-ng"
Revert "toolchain/toolchain-buildroot: enable uclibc for riscv64" This reverts commit bd9810e176273914eca1208bcba23f0de9e446b3. Indeed, while uClibc-ng has support for RISC-V 64-bit, this support lacks the __riscv_flush_icache() function call, which is used by some GCC builtins used for example in libffi. Due to this missing __riscv_flush_icache(), anything that links against libffi fails to build: /home/test/autobuild/run/instance-0/output-1/host/bin/riscv64-buildroot-linux-uclibc-gcc -o gobject/gobject-query gobject/gobject-query.p/gobject-query.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wl,--start-group glib/libglib-2.0.so.0.6400.4 gobject/libgobject-2.0.so.0.6400.4 -Wl,--end-group -pthread '-Wl,-rpath,$ORIGIN/../glib:$ORIGIN/' -Wl,-rpath-link,/home/test/autobuild/run/instance-0/output-1/build/libglib2-2.64.4/build/glib -Wl,-rpath-link,/home/test/autobuild/run/instance-0/output-1/build/libglib2-2.64.4/build/gobject /home/test/autobuild/run/instance-0/output-1/host/lib/gcc/riscv64-buildroot-linux-uclibc/9.3.0/../../../../riscv64-buildroot-linux-uclibc/bin/ld: /home/test/autobuild/run/instance-0/output-1/host/riscv64-buildroot-linux-uclibc/sysroot/usr/lib64/libffi.so.7: undefined reference to `__riscv_flush_icache' collect2: error: ld returned 1 exit status Note that this commit means that support/config-fragments/autobuild/br-riscv64-full-internal.config will be back to using glibc as the C library, but that is OK, until uClibc-ng is fixed to implemented __riscv_flush_icache(). This uClibc-ng issue has been reported upstream at https://mailman.uclibc-ng.org/pipermail/devel/2020-August/002022.html. Fixes: http://autobuild.buildroot.net/results/ec1185ad1fd8863a3990143a0af2ace987761a27/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-08-15 08:10:38 -06:00
depends on BR2_aarch64 || BR2_aarch64_be || BR2_arcle || BR2_arceb || \
BR2_arm || BR2_armeb || \
BR2_i386 || BR2_m68k || BR2_microblaze || \
BR2_mips || BR2_mipsel || BR2_mips64 || BR2_mips64el || \
toolchain/toolchain-buildroot: only riscv64 is supported by uClibc-ng The commit [1] enabled riscv32 and riscv64 for uClibc-ng internal toolchain backend but only riscv64 is curently supported by uClibc-ng. The initial patch [2] from Mark Corbin is only about riscv64. Remove riscv32 from uClibc-ng supported architecture list. Fixes: https://gitlab.com/buildroot.org/buildroot/-/jobs/830981656 [1] 209a082478fca143394512bb9a6c0822f12cfe2c [2] bd9810e176273914eca1208bcba23f0de9e446b3 Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-11-12 16:20:52 -07:00
BR2_or1k || BR2_powerpc || BR2_RISCV_64 || BR2_sh2a || \
toolchain/toolchain-buildroot: allow uclibc-ng for riscv uclibc-ng supports the RISC-V architecture since version 1.0.31, so let's allow selecting this C library when RISC-V is used. There was a previous attempt in commit bd9810e176273914eca1208bcba23f0de9e446b3, which was reverted in e7d631c0df1698b4edc94f148e7247869430e108, due to uClibc-ng not implementing the __riscv_flush_icache() which is needed by gcc. However this function has been implemented in upstream uClibc-ng as of 1.0.35, so we can now safely re-enable uClibc-ng on RISC-V. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-09-08 05:33:19 -06:00
BR2_sh4 || BR2_sh4eb || BR2_sparc || BR2_xtensa || \
BR2_x86_64
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-03-31 23:08:38 -06: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 13:29:12 -06: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 14:53:47 -06: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 13:29:12 -06: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 14:53:47 -06: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 13:29:12 -06: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 10:06:33 -06: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 10:57:30 -07:00
bool "glibc"
aarch64: add big endian(aarch64_be) support Add aarch64_be support. Note that CONFIG_CPU_BIG_ENDIAN should be defined in kernel config when building a big endian kernel. Signed-off-by: Zhang Jian(Bamvor) <bamvor.zhangjian@huawei.com> Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-18 03:49:48 -06:00
depends on BR2_arm || BR2_armeb || BR2_aarch64 || \
BR2_aarch64_be || BR2_i386 || BR2_mips || \
BR2_mipsel || BR2_mips64 || BR2_mips64el|| \
BR2_powerpc || BR2_powerpc64 || BR2_powerpc64le || \
toolchain: add support for the internal IBM s390x and Z toolchain Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-09-16 22:07:52 -06:00
BR2_riscv || BR2_s390x || BR2_sh || \
BR2_sparc64 || BR2_x86_64 || BR2_microblaze || \
BR2_nios2 || (BR2_arc && BR2_ARC_ATOMIC_EXT) || BR2_csky
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 11:31:27 -07:00
depends on BR2_USE_MMU
Rename BR2_PREFER_STATIC_LIB to BR2_STATIC_LIBS Since a while, the semantic of BR2_PREFER_STATIC_LIB has been changed from "prefer static libraries when possible" to "use only static libraries". The former semantic didn't make much sense, since the user had absolutely no control/idea of which package would use static libraries, and which packages would not. Therefore, for quite some time, we have been starting to enforce that BR2_PREFER_STATIC_LIB should really build everything with static libraries. As a consequence, this patch renames BR2_PREFER_STATIC_LIB to BR2_STATIC_LIBS, and adjust the Config.in option accordingly. This also helps preparing the addition of other options to select shared, shared+static or just static. Note that we have verified that this commit can be reproduced by simply doing a global rename of BR2_PREFER_STATIC_LIB to BR2_STATIC_LIBS plus adding BR2_PREFER_STATIC_LIB to Config.in.legacy. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-12-03 14:41:29 -07:00
depends on !BR2_STATIC_LIBS
glibc: remove version choice We do not support uClibc-ng/musl C library version choice support, do the same for GNU C Library. No legacy handling required as only version choice is removed. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Thomas: move 3.2 kernel headers dependency to the libc choice in toolchain/toolchain-buildroot/Config.in file, and added a Config.in comment about it.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-06-10 14:53:37 -06:00
depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2
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 15:24:02 -06:00
depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_10 || !BR2_powerpc64le
toolchain/buildroot: glibc requires kernel headers >= 4.5 with NaN-2008 From sysdeps/unix/sysv/linux/mips/configure.ac in glibc: if test -z "$arch_minimum_kernel"; then if test x$libc_cv_mips_nan2008 = xyes; then arch_minimum_kernel=4.5.0 fi fi 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> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-09-03 03:53:52 -06:00
depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_5 || !BR2_MIPS_NAN_2008
package/{glibc, localedef}: bump to version 2.31 For glibc 2.31.x: - Update LICENSES file hash due to url change: "Prefer https to http for gnu.org and fsf.org URLs" - riscv64 does not build with kernel headers < 5.0, but upstream has not yet comitted a single fix, neither in master nor in the maintenance branch: https://sourceware.org/ml/libc-alpha/2020-02/msg00018.html For localedef 2.31.x: - Remove upstream patch for localedef: 0003-localedef-Use-initializer-for-flexible-array-member-.patch Note that this version bump required some patches applied on several packages (already applied): [Busybox] 13f2d688a24f47446af236829bd6ca194d5aea5b [openssh] bad75bca315dbd2c69f8a9cb02fa9f27636e3d48 [gcc] disable libsanitizer with gcc 7.5 See: https://sourceware.org/legacy-ml/libc-announce/2020/msg00001.html Tested by toolchain builder: https://gitlab.com/kubu93/toolchains-builder/pipelines/129551000 Signed-off-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-07-27 03:29:49 -06:00
depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_0 || !BR2_RISCV_64
toolchain/toolchain-buildroot: glibc 2.32 for ARC needs linux-headers >= 5.1.0 The ARC support has been merged into glibc 2.32 but it requires linux-headers >= 5.1.0 [1]. Fixes: https://gitlab.com/kubu93/toolchains-builder/-/jobs/895774971 [1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=0be8ae3679570ff9a193615a035fc8074a8c704f Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: ARC Maintainers <arc-buildroot@synopsys.com> Acked-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-12-07 15:47:19 -07:00
depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_1 || !BR2_arc
glibc: doesn't build for PowerPC SPE Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-22 16:16:14 -06:00
depends on !BR2_powerpc_SPE
arch: add support for RISC-V 64-bit (riscv64) architecture This enables a riscv64 system to be built with a Buildroot generated toolchain (gcc >= 7.x, binutils >= 2.30, glibc only). This configuration has been used to successfully build a qemu-bootable riscv-linux-4.15 kernel (https://github.com/riscv/riscv-linux.git). Signed-off-by: Mark Corbin <mark.corbin@embecosm.com> [Thomas: - simplify arch.mk.riscv by directly setting GCC_TARGET_ARCH - simplify glibc.mk changes by using GLIBC_CONF_ENV.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-12 04:22:54 -06:00
depends on BR2_RISCV_ISA_RVA || !BR2_riscv
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 11:31:27 -07: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 10:06:33 -06:00
help
This option selects glibc as the C library for the
cross-compilation toolchain.
http://www.gnu.org/software/libc/
glibc: remove version choice We do not support uClibc-ng/musl C library version choice support, do the same for GNU C Library. No legacy handling required as only version choice is removed. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Thomas: move 3.2 kernel headers dependency to the libc choice in toolchain/toolchain-buildroot/Config.in file, and added a Config.in comment about it.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-06-10 14:53:37 -06:00
comment "glibc needs a toolchain w/ dynamic library, kernel headers >= 3.2"
toolchain-buildroot: update glibc comment for noMMU glibc is not available for noMMU platforms, so it doesn't make sense to show the comment about glibc requiring dynamic libraries on noMMU platforms. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-31 13:00:09 -06:00
depends on BR2_USE_MMU
glibc: remove version choice We do not support uClibc-ng/musl C library version choice support, do the same for GNU C Library. No legacy handling required as only version choice is removed. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> [Thomas: move 3.2 kernel headers dependency to the libc choice in toolchain/toolchain-buildroot/Config.in file, and added a Config.in comment about it.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-06-10 14:53:37 -06:00
depends on BR2_STATIC_LIBS || !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 10:57:31 -07: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 15:24:02 -06: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 08:19:02 -07: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-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 15:17:08 -06: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-16 16:13:02 -06:00
bool "musl"
musl: enable or1k architecture With Linux kernel >= 4.13.x musl or1k can be used with Qemu. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-11-29 23:00:28 -07:00
depends on BR2_aarch64 || BR2_arm || BR2_armeb || BR2_i386 || \
BR2_microblaze || BR2_mips || BR2_mipsel || BR2_mips64 || \
BR2_mips64el || BR2_or1k || BR2_powerpc || BR2_powerpc64 || \
toolchain-buildroot: musl only supports 64bit variant of risc-v Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-07-30 10:39:31 -06:00
BR2_powerpc64le || BR2_RISCV_64 || BR2_sh || BR2_x86_64
toolchain/musl: disable for PowerPC SPE It's not supported and the build breaks. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-10 14:16:04 -06:00
depends on !BR2_powerpc_SPE # not supported, build breaks
toolchain/toolchain-buildroot: PPC64(LE) support in musl requires ALTIVEC musl currently assumes all PPC64(LE) CPUs support ALTIVEC instructions. However, there are exceptions (such as the e5500) for which musl builds ultimately generate illegal instructions for the targets. Disable musl if the PPC64(LE) CPU does not support ALTIVEC instructions. This patch addresses the issues seen here: https://gitlab.com/kubu93/toolchains-builder/-/jobs/418092743 https://gitlab.com/kubu93/toolchains-builder/-/jobs/418092744 musl mailing list thread: https://www.openwall.com/lists/musl/2020/02/03/10 Signed-off-by: Vincent Fazio <vfazio@xes-inc.com> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-02-04 14:35:48 -07:00
depends on !(BR2_powerpc64 || BR2_powerpc64le) || BR2_POWERPC_CPU_HAS_ALTIVEC
toolchain-buildroot: don't show musl on noMMU platforms While musl has recently gained noMMU support for the sh2 platform, we don't support this yet. So for the time being, let's not show musl as an available C library on noMMU platforms. This is for example important on ARM noMMU: ARM is supported by musl, but not its noMMU variants. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-31 13:00:10 -06:00
# sh2 nommu is supported by musl, but we don't have support
# for it in Buildroot.
depends on BR2_USE_MMU
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 15:17:08 -06: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 10:58:42 -07: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 13:29:12 -06: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 10:06:33 -06: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 15:17:08 -06: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 13:29:12 -06: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 12:34:59 -06: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-29 16:10:38 -07: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 13:02:22 -07: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 13:29:05 -06: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 10:43:46 -07: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 04:39:01 -07: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 13:29:03 -06:00
source "package/gcc/Config.in.host"
toolchain: move elf2flt option inclusion to toolchain-buildroot/Config.in The only remaining thing in toolchain-buildroot/Config.in.2 is the inclusion of the elf2flt option. It doesn't really make sense to have a separate Config.in file for that, so let's move this to toolchain-buildroot/Config.in. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-09-02 10:06:37 -06:00
source "package/elf2flt/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 08:28:48 -07:00
endif
Reference in a new issue Copy permalink