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>
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>
Startig with glibc 2.34, the gconv modules description has been split in
two:
- a common definition in the old location, /usr/lib/gconv/gconv-modules
- specific definitions in a subdirectory, /usr/lib/gconv/gconv-modules.d/
This is done so as to simplify the handling of glibc gconv modules, and
eventually to segregate those outside of glibc, and so that third-parties
may also provide their own gconv converters and their definitions.
And starting with that same glibc version, most of the gconv modules
definitions are moved to an extra configuration file in that
sub-directory.
It is thus no longer possible to use special code pages, like cp850,
which are very useful to access FAT-formatted devices.
Add support for this new gconv layout, while keeping support for older
glibc versions. Note that the modules themselves are not moved or
renamed, just the definition files have changed.
Instead of passing the one old gonv modules definitions file on stdin,
we pass the base directory to that file, and move into the script the
responsibility to find all the gconv definition files.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Romain Naour <romain.naour@gmail.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Cc: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
As reported to Linaro bug tracker [1] the Arm GNU Toolchain generated
since 2022.02 doesn't work on all x86_64 host.
It still not fixed with 11.3.Rel1 release (2022.08).
Fixes#15006
[1] https://bugs.linaro.org/show_bug.cgi?id=5825#c19
This reverts commit 34cf3a15c9.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
As reported to Linaro bug tracker [1] the Arm GNU Toolchain generated
since 2022.02 doesn't work on all x86_64 host.
It still not fixed with 11.3.Rel1 release (2022.08).
Fixes#15006
[1] https://bugs.linaro.org/show_bug.cgi?id=5825#c19
This reverts commit f4a78565db.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
As reported to Linaro bug tracker [1] the Arm GNU Toolchain generated
since 2022.02 doesn't work on all x86_64 host.
It still not fixed with 11.3.Rel1 release (2022.08).
Fixes#15006
[1] https://bugs.linaro.org/show_bug.cgi?id=5825#c19
This reverts commit 22d10e294c.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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] 68d0aede59
[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>
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>
This makes the condition easier to read and it's easier to maintain the
gcc bug too because we don't have to take care about new gcc versions.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[yann.morin.1998@free.fr: fix comment while at it]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This makes the condition easier to read and it's easier to maintain the
gcc bug too because we don't have to take care about new gcc versions.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Back many years ago, we developed an Eclipse plugin that simplified
the usage of Buildroot toolchains. Enabling the BR2_ECLIPSE_REGISTER=y
was registering the Buildroot toolchain into a special file in your
HOME folder that the Eclipse plugin would recognize to allow to
directly use the Buildroot cross-compiler.
This Eclipse plugin has not been maintained for years. The last commit
in the repository dates back from September 2017. Since then Eclipse
has moved on, and the plugin is no longer compatible with current
versions of Eclipse.
Also, Eclipse is probably no longer that widely used in the embedded
Linux space, as other more modern IDEs have become more popular.
All in all, it's time to say good bye to this Eclipse integration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Gcc bug 99410 reappeared while building with gcc 11.x and while
testing it also shows up with gcc 12.x, so let's enable this bug for
all gcc versions except gcc 8.x.
Fixes:
http://autobuild.buildroot.net/results/64e54ef5ba3a3dee391b788315615d57a1dd9fa2/
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
While introducing gcc bug 99410 I've named BR2_TOOLCHAIN_HAS_GCC_BUG_ to
99140 that is wrong. So let's fix this by changing bug option to
BR2_TOOLCHAIN_HAS_GCC_BUG_99410.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
It's time to finally switch over globally to the new spacing format
that we have agreed on for the hash file, with 2 spaces as a separator
between fields.
This commit was mechanically generated using:
find . -type f -name '*.hash' | xargs sed -i 's%^md5[ \t]*\([^ \t]*\)[ \t]*\(.*\)$%md5 \1 \2%'
find . -type f -name '*.hash' | xargs sed -i 's%^sha1[ \t]*\([^ \t]*\)[ \t]*\(.*\)$%sha1 \1 \2%'
find . -type f -name '*.hash' | xargs sed -i 's%^sha256[ \t]*\([^ \t]*\)[ \t]*\(.*\)$%sha256 \1 \2%'
find . -type f -name '*.hash' | xargs sed -i 's%^sha512[ \t]*\([^ \t]*\)[ \t]*\(.*\)$%sha512 \1 \2%'
This commit can easily be backported on the LTS branch by re-running
the same commands, if needed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Until now, when BR2_CCACHE=y, ccache support was built into the
toolchain wrapper, and used regardless of whether the toolchain is
using during the Buildroot build itself, or later as part of the SDK.
However, having ccache support forcefully enabled in the SDK can
really be surprising, and is certainly unexpected for a
cross-compilation toolchain. This can be particularly surprising as
the ccache cache directory may be hardcoded in the ccache binary to
point to a folder that does not make sense on the SDK user's machine.
So what this commit does is create a BR2_USE_CCACHE variable, which
when set to 1 tells the toolchain wrapper to use ccache. Not defining
the variable, or specifying any other value that 1 causes the
toolchain wrapper to not use ccache. The main Buildroot Makefile is
modified to export BR2_USE_CCACHE = 1 when ccache support is enabled,
so that ccache is used during the Buildroot build.
However, when someone will use the SDK outside of Buildroot, the
toolchain wrapper will not use ccache.
The BR2_USE_CCACHE variable is only conditionally enabled in the main
Makefile (via ?=) so that it can be overridden in the environment if
one wants to quickly test disabling ccache in a ccache-enabled
Buildroot configuration. This is the scenario that was considered in
commit 792f1278e3 ("toolchain-wrapper:
support change of BR2_CCACHE"), which added the BR_NO_CCACHE variable.
The BR_NO_CCACHE variable is no longer needed, and replaced by this
BR2_USE_CCACHE variable.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
[Thomas: almost entirely rework the implementation and commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Currently, glibc depends on !BR2_STATIC_LIBS in all the toolchain
variants.
However, for some architectures, glibc is the only supported libc. In
commit 3b3105328e ("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 3b3105328e
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>
When changing permissions on all directories in the staging directory,
after copying sysroot, paths that contain spaces break the call to
chmod.
With -print0 for find and -0 for xargs white spaces are correctly
interpreted.
Signed-off-by: Daniel Lang <d.lang@abatec.at>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In commit fd839aeb7f ("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>
There is no need to have configuration files direbtly set the
BR2_PACKAGE_HOST_ELF2FLT option. The need for the elf2flt utility is
automatically determined by gcc build in package/gcc/gcc.mk according to
the BR2_BINFMT_FLAT option.
Accordingly, we can remove the file package/elf2flt/Config.in.host to
get rid of the BR2_PACKAGE_HOST_ELF2FLT option. BR2_STRIP_strip
dependency on this option is replaced with a dependency on
BR2_BINFMT_ELF.
To stay consistent with the fact that elf2flt supports only the arm, sh,
sparc, xtensa and riscv-64 architectures, a dependency on these
architectures is added to the BR2_BINFMT_FLAT option in arch/Config.in.
Board configuration files setting the BR2_PACKAGE_HOST_ELF2FLT option
are also updated.
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
As we're about to remove the nds32 architecture support from
Buildroot, drop the toolchain-external-andes-nds32 external toolchain
package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Yu Chien Peter Lin <peterlin@andestech.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Some external toolchains do not have gdbserver available, but the
option BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY is always visible. And
when enabled, this option aborts with an error when gdbserver cannot
be found:
Could not find gdbserver in external toolchain
Due to that, some random configurations fail to build when
BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY=y, for example with the Bootlin
toolchains for Microblaze or OpenRISC (because there's no GDB support
for those architectures).
One solution could be to make "Could not find gdbserver in external
toolchain" a warning instead of a hard error, but then nobody would
notice about this issue, in cases where it should legitimately abort
with a hard error.
So, the clean solution would be to add a
BR2_TOOLCHAIN_EXTERNAL_HAS_GDBSERVER. But that means all existing
external toolchains would have to be modified to select this option.
Instead, and as an exception, we chose to use inverted logic, and
create an option that is the opposite:
BR2_TOOLCHAIN_EXTERNAL_HAS_NO_GDBSERVER. By default, we assume
external toolchains have gdbserver. If
BR2_TOOLCHAIN_EXTERNAL_HAS_NO_GDBSERVER is enabled, we disallow the
BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY option.
Note that the case of custom external toolchain does not matter: by
definition they are not tested by the autobuilders, and by definition,
we cannot know in menuconfig if the custom toolchain has or does not
have gdbserver. We could make a user-visible option for it, but that
adds no value over simply erroring out because the gdbserver binary
can't be found.
Similarly, we could add
default y if BR2_PACKAGE_GDB_ARCH_SUPPORTS
but that would make it impossible for someone to include a custom
gdbserver in their external toolchain, and gives no benefit at all.
This will help fixing:
http://autobuild.buildroot.net/results/6315ef7b66ee4ae8f870c92186bc674d65f62f2c/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This commit regenerates the toolchain-external-bootlin Config.in file
after the ARM toolchain description was modified to make sure they
only match the ARM little endian configurations.
Fixes:
http://autobuild.buildroot.net/results/7befbb686bb972016ba4e742976dcdb3fed1be11/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This commit allows to get a proper description of the dependencies for
the RISC-V 64-bit toolchain, that includes the BR2_USE_MMU dependency.
Fixes:
http://autobuild.buildroot.net/results/d6aee9b275b1ec399aea59758ac8f69fdc5691fc/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This commit is simply the result of regenerating the
toolchain-external-bootlin package after gen-bootlin-toolchains was
changed in commit "support/scripts/gen-bootlin-toolchains: properly
take into account !BR2_STATIC_LIBS for glibc toolchains".
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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>
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>
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>
