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

101 lines
3.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-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
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.
kernel-headers: migrate to the package infrastructure [Peter: fix file header] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-06-30 21:28:58 +02:00
source "package/linux-headers/Config.in.host"
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: default to uClibc Otherwise we're getting musl for everything except those who have a default (mips64*). Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-06 12:42:44 +02:00
default BR2_TOOLCHAIN_UCLIBC
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 10:49:48 +01:00
default BR2_TOOLCHAIN_BUILDROOT_GLIBC if BR2_aarch64 || BR2_aarch64_be \
toolchain: add mips64 for uClibc-ng Filter out all other uClibc versions, as they containing serious bugs for mips64. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-08-11 07:22:05 +02:00
|| BR2_microblaze || 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
bool "uClibc"
select BR2_TOOLCHAIN_USES_UCLIBC
toolchain: enable microblaze toolchain This commit allows to build an internal toolchain for the Microblaze architecture, with either glibc or eglibc. Note that we add an explicit list of architectures that are supported by uClibc, and Microblaze is not part of them, because it currently doesn't build for this architecture. [Thomas: add better commit log, add architecture dependencies on uClibc, to avoid selecting uClibc on Microblaze] Signed-off-by: Spenser Gilliland <spenser@gillilanding.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-12-05 18:20:56 +01:00
depends on BR2_arcle || BR2_arceb || BR2_arm || BR2_armeb || \
toolchain/buildroot: forget about avr32 Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-14 10:23:08 +01:00
BR2_bfin || BR2_i386 || BR2_m68k || \
toolchain: enable microblaze toolchain This commit allows to build an internal toolchain for the Microblaze architecture, with either glibc or eglibc. Note that we add an explicit list of architectures that are supported by uClibc, and Microblaze is not part of them, because it currently doesn't build for this architecture. [Thomas: add better commit log, add architecture dependencies on uClibc, to avoid selecting uClibc on Microblaze] Signed-off-by: Spenser Gilliland <spenser@gillilanding.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-12-05 18:20:56 +01:00
BR2_mips || BR2_mipsel || BR2_mips64 || BR2_mips64el || \
sh4: fix toolchain creation The Linux kernel does force compile with -m4-nofpu, which is only available when building a multilib toolchain. The interesting part here is, that buildroot use --disable-multilib for gcc configure, but enables --with-multilib-list=m4,m4-nofpu in the default configuration for Qemu targeting r2d emulation. This results in a toolchain, which can be used for the kernel and for userland without creating a multilib toolchain with different kinds of libgcc version. In the multilib case there would be subdirectories created (!m4 and m4-nofpu). As buildroot uses a short version of toolchain creation, a multilib enabled gcc build fails when creating libgcc. So the best solution is to just keep multilib disabled, but always add --with-multilib-list when sh4/sh4eb/sh4a/sh4aeb is choosen. Tested with sh4/sh4a toolchain build and qemu defconfig with gcc 4.8.x/4.9.x (with and without C++ enabled), uClibc and glibc. Disable sh4a/sh4aeb for uClibc, as it does not implemented, yet. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> (ARM and SH4 uClibc toolchain builds)
2015-04-08 10:54:55 +02:00
BR2_powerpc || BR2_sh2a || BR2_sh4 || BR2_sh4eb || \
BR2_sparc || BR2_xtensa || BR2_x86_64
arch: add support for mips32r6 and mips64r6 variants - Add support for mips32r6 and mips64r6 target architecture variants - Disable unsupported gcc versions - Disable unsupported binutils versions - Disable unsupported external toolchains - Disable unsuported C libraries - Add a hook in order to make glibc compile for MIPS R6. [Thomas: slightly tweak the glibc hack explanation, to make it hopefully clearer.] Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-12 12:08:06 +02:00
# Unsupported for MIPS R6
depends on !BR2_mips_32r6 && !BR2_mips_64r6
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
This option selects uClibc as the C library for the
cross-compilation toolchain.
http://uclibc.org
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"
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 10:49:48 +01: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 || \
glibc: remove version 2.21 Mask out glibc for sparc as well since it's no longer available. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-22 13:07:24 +01:00
BR2_sh || BR2_sh64 || BR2_sparc64 || \
BR2_x86_64 || BR2_microblaze || BR2_nios2
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
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 22:41:29 +01:00
depends on !BR2_STATIC_LIBS
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-23 00:16:14 +02:00
depends on !BR2_powerpc_SPE
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
# our glibc.mk enables RPC support
select BR2_TOOLCHAIN_HAS_NATIVE_RPC
help
This option selects glibc as the C library for the
cross-compilation toolchain.
http://www.gnu.org/software/libc/
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
comment "(e)glibc only available with shared lib support"
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 21:00:09 +02: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 22:41:29 +01:00
depends on BR2_STATIC_LIBS
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
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"
toolchain: enable musl for aarch64 musl 1.1.7 brings in experimental aarch64 support so enable it. Tested via qemu_aarch64_virt_defconfig. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-03-19 14:29:15 +01:00
depends on BR2_aarch64 || BR2_arm || BR2_armeb || BR2_i386 || \
BR2_microblaze || BR2_mips || BR2_mipsel || BR2_powerpc || \
toolchain: enable musl for sh The SuperH architecture is supported by the musl libc since some time now, so let's enable it. Tested via qemu_sh4_r2d_defconfig. Signed-off-by: Lionel Orry <lionel.orry@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-25 09:55:30 +01:00
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 22:16:04 +02:00
depends on !BR2_powerpc_SPE # not supported, build breaks
arch: add support for mips32r6 and mips64r6 variants - Add support for mips32r6 and mips64r6 target architecture variants - Disable unsupported gcc versions - Disable unsupported binutils versions - Disable unsupported external toolchains - Disable unsuported C libraries - Add a hook in order to make glibc compile for MIPS R6. [Thomas: slightly tweak the glibc hack explanation, to make it hopefully clearer.] Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-10-12 12:08:06 +02:00
# Unsupported for MIPS R6
depends on !BR2_mips_32r6 && !BR2_mips_64r6
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 21:00:10 +02: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 23:17:08 +02:00
select BR2_TOOLCHAIN_USES_MUSL
help
This option selects musl as the C library for the
cross-compilation toolchain.
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
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: 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 18:06:37 +02: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 16:28:48 +01:00
endif
Reference in New Issue Copy Permalink