2010-07-28 00:08:16 +02:00
|
|
|
# Config entries for internal toolchain backend
|
2008-12-15 16:28:48 +01:00
|
|
|
|
2009-12-14 12:10:12 +01:00
|
|
|
if BR2_TOOLCHAIN_BUILDROOT
|
2014-04-01 08:25:47 +02:00
|
|
|
|
2016-08-08 20:34:59 +02:00
|
|
|
comment "Toolchain Buildroot Options"
|
|
|
|
|
|
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.
|
|
|
|
|
|
2013-06-30 21:29:12 +02:00
|
|
|
choice
|
|
|
|
|
prompt "C library"
|
toolchain/toolchain-buildroot: default to glibc as the C library
This is perhaps the most controversial change for Buildroot that can
be written in a two-liner.
Historically, we have used uClibc as our default C library, as
Buildroot was created initially as a test-bed for uClibc, and also
because uClibc made a lot of sense for embedded Linux systems, due to
its smaller size and fine-grained configurability.
Since then, the landscape of embedded Linux systems has changed. Even
though Buildroot happily supports really low-end devices, the vast
majority of Buildroot users are quite certainly running the resulting
system on a reasonably powerful platform, with significant amount of
RAM and storage. In this context, the benefits of uClibc are no longer
that much relevant, and glibc causes less "troubles". Therefore, this
patch proposes to use glibc as our default C library when using the
internal toolchain backend instead of uClibc.
Of course, we will keep the support for uClibc, which remains an
important C library choice, for space-constrained systems, or simply
for architectures that are not supported by glibc.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
Acked-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-08-15 22:29:55 +02:00
|
|
|
default BR2_TOOLCHAIN_BUILDROOT_GLIBC
|
2013-06-30 21:29:12 +02:00
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_BUILDROOT_UCLIBC
|
2016-06-04 22:53:47 +02:00
|
|
|
bool "uClibc-ng"
|
2022-06-05 21:42:53 +02:00
|
|
|
depends on BR2_PACKAGE_UCLIBC_SUPPORTS
|
2018-04-01 07:08:38 +02:00
|
|
|
select BR2_TOOLCHAIN_USES_UCLIBC
|
2013-06-30 21:29:12 +02:00
|
|
|
help
|
2016-06-04 22:53:47 +02:00
|
|
|
This option selects uClibc-ng as the C library for the
|
2013-06-30 21:29:12 +02:00
|
|
|
cross-compilation toolchain.
|
|
|
|
|
|
2016-06-04 22:53:47 +02:00
|
|
|
http://uclibc-ng.org
|
2013-06-30 21:29:12 +02:00
|
|
|
|
2013-09-02 18:06:33 +02:00
|
|
|
config BR2_TOOLCHAIN_BUILDROOT_GLIBC
|
2013-11-11 18:57:30 +01:00
|
|
|
bool "glibc"
|
2022-06-05 21:42:54 +02:00
|
|
|
depends on BR2_PACKAGE_GLIBC_SUPPORTS
|
2014-03-03 19:31:27 +01:00
|
|
|
select BR2_TOOLCHAIN_USES_GLIBC
|
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"
|
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
|
2013-11-11 18:57:31 +01:00
|
|
|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
|
package/glibc: headers >= 5.4 needed on RISC-V 32-bit
Since glibc 2.33 (upstream commit
7a55dd3fb6d2c307a002a16776be84310b9c8989), headers >= 5.4.0 are needed
to build glibc for RISC-V 32-bit. Indeed
sysdeps/unix/sysv/linux/riscv/configure.ac contains:
if test $libc_cv_riscv_int_abi = ilp32; then
arch_minimum_kernel=5.4.0
fi
In order to take into account this dependency, we add the appropriate
logic in package/glibc/Config.in and
toolchain/toolchain-buildroot/Config.in.
This change means that if headers < 5.4.0 are selected, then no C
library at all will be available for RISC-V 32-bit, as glibc is the
only C library supporting RISC-V 32-bit currently. However, thanks to
the recent addition of BR2_TOOLCHAIN_BUILDROOT_NONE, the
choice...endchoice for the C library selection will not be empty,
allowing the user to see the Config.in comment explaining why glibc
can't be selected.
Therefore, technically this commit does prevent from creating a
configuration with RISC-V 32-bit and headers < 5.4.0, but it will have
BR2_TOOLCHAIN_BUILDROOT_NONE=y, which is catched by
package/Makefile.in, which aborts the build early on pointing out that
the configuration is invalid.
Fixes:
http://autobuild.buildroot.net/results/5ca49b2732f68eccb5276e7112f7f496dcc514ee/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-10-26 20:34:27 +02:00
|
|
|
comment "glibc on RISC-V 32-bit needs a toolchain w/ headers >= 5.4"
|
|
|
|
|
depends on BR2_RISCV_32
|
|
|
|
|
depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_4
|
|
|
|
|
|
2022-07-26 15:42:02 +02:00
|
|
|
comment "glibc on ARC needs a toolchain w/ headers >= 5.1"
|
|
|
|
|
depends on BR2_arc
|
|
|
|
|
depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_1
|
|
|
|
|
|
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
|
|
|
|
|
|
2014-05-05 23:17:08 +02:00
|
|
|
config BR2_TOOLCHAIN_BUILDROOT_MUSL
|
2016-05-17 00:13:02 +02:00
|
|
|
bool "musl"
|
2022-06-05 21:42:55 +02:00
|
|
|
depends on BR2_PACKAGE_MUSL_SUPPORTS
|
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.
|
|
|
|
|
|
2019-11-28 18:58:42 +01:00
|
|
|
https://www.musl-libc.org/
|
|
|
|
|
|
toolchain/toolchain-buildroot: introduce BR2_TOOLCHAIN_BUILDROOT_NONE
In the internal toolchain backend, we have a choice..endchoice block
to allow the user to select the C library, between glibc, uClibc and
musl.
However, there are situations were no C library at all is
supported. In this case, the choice does not appear, and does not
allow to see the Config.in comments that are within the
choice..endchoice block and that may explain why no C library is
available.
For example, on RISC-V 32-bit, the only C library supported is glibc,
and the minimum kernel header version required by glibc on this
architecture is 5.4.0. In a future commit, we are going to add this
dependency on glibc (to fix build issues on configurations that have
headers < 5.4.0). But since glibc is the only supported C library on
RISC-V 32-bit, it means that the choice..endchoice for the C library
contains no entry, preventing from seeing the Config.in comment.
To address this issue, this commit adds a "dummy"
BR2_TOOLCHAIN_BUILDROOT_NONE option that shows up in the
choice..endchoice only when no C library is available. Thanks to this,
the choice..endchoice is never empty, and the Config.in comments can
be seen.
If the user keeps BR2_TOOLCHAIN_BUILDROOT_NONE selected, then the
build will anyway abort early because package/Makefile.in has a check
to verify that a C library is selected, and aborts the build if not.
Some could say that the problem should be resolved by instead
preventing the selection of headers < 5.4.0 on RISC-V 32-bit, but that
is difficult to do as the user can choose a custom header version, or
simply specific that (s)he wants to use the headers of the kernel
being built. In those situations, it's difficult to prevent selecting
headers < 5.4.0.
Prevent random configurations from triggering a build failure in our
autobuilders, by excluding that symbol from accepted configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: update genrandconfig]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-10-26 20:34:26 +02:00
|
|
|
config BR2_TOOLCHAIN_BUILDROOT_NONE
|
|
|
|
|
bool "none"
|
|
|
|
|
depends on !BR2_PACKAGE_UCLIBC_SUPPORTS && \
|
|
|
|
|
!BR2_PACKAGE_GLIBC_SUPPORTS && \
|
|
|
|
|
!BR2_PACKAGE_MUSL_SUPPORTS
|
|
|
|
|
help
|
|
|
|
|
This option is visible if no C library is available for the
|
|
|
|
|
currently selected configuration. If you select this option,
|
|
|
|
|
the build will refuse to start as Buildroot needs a C
|
|
|
|
|
library to build a toolchain. Change your configuration
|
|
|
|
|
settings to make sure one of the C libraries is selected.
|
|
|
|
|
|
2013-06-30 21:29:12 +02:00
|
|
|
endchoice
|
|
|
|
|
|
|
|
|
|
config BR2_TOOLCHAIN_BUILDROOT_LIBC
|
|
|
|
|
string
|
|
|
|
|
default "uclibc" if BR2_TOOLCHAIN_BUILDROOT_UCLIBC
|
2013-09-02 18:06:33 +02:00
|
|
|
default "glibc" if BR2_TOOLCHAIN_BUILDROOT_GLIBC
|
2014-05-05 23:17:08 +02:00
|
|
|
default "musl" if BR2_TOOLCHAIN_BUILDROOT_MUSL
|
2013-06-30 21:29:12 +02:00
|
|
|
|
2016-08-08 20:34:59 +02:00
|
|
|
source "package/linux-headers/Config.in.host"
|
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"
|
2013-06-30 21:29:05 +02:00
|
|
|
source "package/uclibc/Config.in"
|
2014-02-10 18:43:46 +01:00
|
|
|
source "package/glibc/Config.in"
|
2010-12-31 12:39:01 +01:00
|
|
|
source "package/binutils/Config.in.host"
|
2013-06-30 21:29:03 +02:00
|
|
|
source "package/gcc/Config.in.host"
|
2008-12-15 16:28:48 +01:00
|
|
|
endif
|
