This toolchain is pretty old and unlikely used. It's also affected by
binutils bug 27597, so let's remove it.
Remove BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII from pixman package.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Romain: remove BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Note: this commit only deals with glibc and its internal libcrypt (or
lack thereof); other C libraries, musl and uClibc-NG, are not considered.
libcrypt from glibc has been deprecated for a long time, and it has now
been entirely dropped with glibc 2.39. Now, packages that need crypt(3)
features need to explicitly depend on the libxcrypt pacakge.
However, the set of files installed both by glibc and libxcrypt is not
empty:
glibc libxcrypt
/usr/include/crypt.h /usr/include/crypt.h
/usr/lib/libcrypt.a /usr/lib/libcrypt.a
/usr/lib/libcrypt.so /usr/lib/libcrypt.so
/lib/libcrypt.so.1
/lib/libcrypt-2.23.so
/usr/lib/libcrypt.so.2
The two libraries have different SO_NAME, so they do not conflict on the
library filename. However, the .so synlink is present in both, and thus
conflicts. The header and the static library also conflict.
So, the situation is that, with a glibc 2.39 or later, packages have to
use libxcrypt, which is a drop-in replacement. With glibc 2.38 or
earlier, they can use either.
Since we already bumped to glibc 2.39 for the internal toolchain, we
have already converted quite a few packages to use libxcrypt. That works
well with an internl toolchain, because glibc does not install the
conflicting files.
However, for external toolchains, we may very well end up in three
situations:
- a glibc 2.39 or later, without libcrypt
- a glibc 2.39 or later, without libcrypt, but with libxcrypt [0]
- a glibc 2.38 or earlier with libcrypt
In the first case, all is OK and we are in a situation similar to the
internal toolchain, but in the latter two cases, we end up with a
conflict.
We could introduce BR2_TOOLCHAIN_EXTERNAL_HAS_LIBCRYPT os something
along those lines, but this is going to be a bit complex on packages,
which would have to select LIBXCRYPT if GLIBC && !_HAS_LIBCRYPT.
So, to simplify things, we want to get the external toolchains into a
situation similar to the internal one, where libcrypt is not provided by
the toolchain; packages have to select libxcrypt for glibc toolchains,
without having to care whether this is an internal or external toolchain
or some more complex conditions.
So, we remove from staging whatever could be used to compile and link
with libcrypt. We however keep the SO_NAME file, if it exists, and we
also install it in target/, for those pre-built binaries that may be
linked with it [1]. The glibc SO_NAME has always been libcrypt.so.1, so
this is what we copy exactly, to avoid copying the libxcrypt one, which
is libcrypt.so.2.
[0] that could happen if a toolchain provider tried to be helpful and
suplies a toolchain with libxcrypt to be trasnparent to users, in which
case that would conflict with ours...
[1] if such a prebuilt binary (executable or library) is used with a
glibc 2.39 or later toolchain, it will obviously not work at all.
libxcrypt is supposed to be a drop-in replacement for glibc's libcrypt,
so we could look into symlinking libcrypt.so.1 to libcrypt.so.2. In a
later patch, maybe...
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2024.02 Bootlin toolchains have been released, so let's update the
support in Buildroot. Notable changes:
- Bleeding edge toolchains now use binutils 2.42, and stable
toolchains use binutils 2.41. This fixes binutils bug 27597
for both.
- glibc has been updated to 2.39
- musl has been updated to 1.2.5, which brings 32-bit RISC-V
support. Due to this, 2 new toolchain variants are added: 32-bit
RISC-V stable, 32-bit RISC-V bleeding edge.
- Bleeding edge toolchains now use 5.15 kernel headers, and stable
toolchains now use 4.19 kernel headers
- Fortran support has been disabled on Microblaze, as the libgfortran
build at -O2 causes an internal compiler error.
All runtime tests are passing, except the ones for the new RISC-V
32-bit musl toolchain, for which Busybox fails to build due to an
interaction between musl-specific code in Busybox and musl. This issue
has been reported:
https://www.openwall.com/lists/musl/2024/03/03/2
The runtime tests are nevertheless included, with the hope that this
issue will reasonably quickly be resolved.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Codescape mips toolchains are old (2018) and use glibc 2.20 which is not
compatible with 64-bit time_t raising the following build failure with
libselinux since commit 1c2dbcdcf0:
In file included from selinux_restorecon.c:17:0:
/home/buildroot/autobuild/instance-1/output-1/host/mipsel-buildroot-linux-gnu/sysroot/usr/include/fts.h:41:3: error: #error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
# error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
^~~~~
Fixes: 1c2dbcdcf0
- http://autobuild.buildroot.org/results/a4d38af627a42a2c55d60129787c51353d5883bf
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
codesourcery arm/aarch64 toolchains are old (2014) and use glibc
2.18/2.20 which are not compatible with 64-bit time_t raising the
following build failure with libcgroup since commit
1c2dbcdcf0:
In file included from ./libcgroup-internal.h:25:0,
from parse.y:21:
/home/buildroot/autobuild/run/instance-3/output-1/host/arm-buildroot-linux-gnueabi/sysroot/usr/include/fts.h:41:3: error: #error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
# error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
^
Fixes: 1c2dbcdcf0
- http://autobuild.buildroot.org/results/e28f955f2b360f6e7bb231a5a3800cfbd17a23d7
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Peter: add Config.in.legacy entries]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
New toolchains have been released, with the following changes:
- The bleeding-edge toolchains are based on gcc 13.2, binutils 2.41,
gdb 14.1, kernel headers 5.10, glibc 2.38, musl 1.2.4 or uclibc-ng
1.0.45.
- The stable toolchains are based on gcc 12.3, binutils 2.40, gdb
13.2, kernel headers 4.14, glibc 2.38, musl 1.2.4 or uclibc-ng
1.0.45.
- The glibc version is no longer affected by CVE-2023-4911
- The gdb build has been fixed to no longer rely on uninstalled
libbfd.so and libopcodes.so libraries
- The zlib library, which was incorrectly present in the toolchain
sysroot, is gone, fixing various build failures encountered with
2023.08 toolchains.
- There are now toolchains for m68k 68xxx based on uclibc and musl in
addition to glibc, which was already supported
The careful reviewer will notice that a number of
depends on !BR2_ARCH_NEEDS_GCC_AT_LEAST_14
are being added to the toolchains that use gcc 13.x, as per
a0d2a5cfec
("support/scripts/gen-bootlin-toolchains: generate
BR2_ARCH_NEEDS_GCC_AT_LEAST_X guard").
All 214 test cases were successfully run:
https://gitlab.com/tpetazzoni/buildroot/-/pipelines/1120323562
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Updated to gcc 13.2, gdb 13, binutils 2.41, glibc 2.38.
The x86_64 host variant prebuilt toolchain is built on RHEL7
(glibc 2.17) and is likely also be useable on OS versions like
RHEL8, Ubuntu 18.04 or later.
The AArch64 host variant prebuilt toolchain is built on Ubuntu 18.04
(glibc 2.27) is likely also be useable on OS versions like RHEL8,
Ubuntu 18.04 or later.
Release note:
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Updated to gcc 13.2, gdb 13, binutils 2.41, glibc 2.38.
The x86_64 host variant prebuilt toolchain is built on RHEL7
(glibc 2.17) and is likely also be useable on OS versions like
RHEL8, Ubuntu 18.04 or later.
The AArch64 host variant prebuilt toolchain is built on Ubuntu 18.04
(glibc 2.27) is likely also be useable on OS versions like RHEL8,
Ubuntu 18.04 or later.
Tested with qemu_aarch64_virt_defconfig.
Release note:
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Updated to gcc 13.2, gdb 13, binutils 2.41, glibc 2.38.
The x86_64 host variant prebuilt toolchain is built on RHEL7
(glibc 2.17) and is likely also be useable on OS versions like
RHEL8, Ubuntu 18.04 or later.
The AArch64 host variant prebuilt toolchain is built on Ubuntu 18.04
(glibc 2.27) is likely also be useable on OS versions like RHEL8,
Ubuntu 18.04 or later.
Tested with qemu_arm_vexpress_defconfig.
Release note:
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Currently, when verifying the configuration of a uClibc toolchain for
the presence of locale support, we check __UCLIBC_HAS_LOCALE__. It
turns out that we in fact also expect __UCLIBC_HAS_XLOCALE__ to be
defined, as without it locale_t is not defined, causing build failure
in some packages, such as libcpprestsdk:
In file included from /home/thomas/autobuild/instance-0/output-1/build/libcpprestsdk-2.10.18/Release/include/cpprest/json.h:18,
from /home/thomas/autobuild/instance-0/output-1/build/libcpprestsdk-2.10.18/Release/src/pch/stdafx.h:88,
from /home/thomas/autobuild/instance-0/output-1/build/libcpprestsdk-2.10.18/Release/src/http/client/http_client_msg.cpp:13:
/home/thomas/autobuild/instance-0/output-1/build/libcpprestsdk-2.10.18/Release/include/cpprest/asyncrt_utils.h:317:13: error: 'locale_t' does not name a type
317 | typedef locale_t xplat_locale;
| ^~~~~~~~
As essentially our requirement for uClibc in external toolchains is
"it should match the uClibc configuration used by Buildroot for
internal toolchains", it makes sense to verify
__UCLIBC_HAS_XLOCALE__. Note that of course checking
__UCLIBC_HAS_XLOCALE__ is sufficient, as it cannot be enabled if
__UCLIBC_HAS_LOCALE isn't.
This addresses an issue with the Synopsys ARC external toolchain,
which is built with __UCLIBC_HAS_LOCALE__, but without
__UCLIBC_HAS_XLOCALE__ causing a build failure with some
packages (such as libcpprestsdk).
Therefore, this patch also changes how the Synospys ARC external
toolchain is exposed in Buildroot: it no longer advertise locale
support.
Fixes:
http://autobuild.buildroot.org/results/e6778e60cc1ea455f5b4511d5824f04d8040f67b
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Previously, gen-bootlin-toolchains did not add a `depends` guard to
limit the available toolchains based on the minimum required GCC version
for the user selected CPU tuning.
Now, the proper BR2_ARCH_NEEDS_GCC_AT_LEAST_X guard will be added based
on the version of GCC provided by the toolchain.
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
[yann.morin.1998@free.fr: regenerate the toolchain list]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Previously, it was possible to select an external toolchain that did not
support the GCC arch tuning the user had selected. This is problematic
because it can lead to confusing error messages during builds [0].
Now, external toolchain selections will be filtered to only those that
support the required GCC version specified by the target arch tuning.
Note: this patch does not touch the Bootlin toolchain config file as it
is generated by a script.
Additional note: there is "soft" support for toolchains prior to GCC 4.8
but there are no accompanying BR2_ARCH_NEEDS_GCC_AT_LEAST_X symbols.
Instead of adding those, just use BR2_ARCH_NEEDS_GCC_AT_LEAST_4_8 which
is the minimum GCC version with claimed support [1].
[0]: https://lists.buildroot.org/pipermail/buildroot/2023-August/671877.html
[1]: https://buildroot.org/downloads/manual/manual.html#requirement-mandatory
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
A new version of Bootlin toolchains, 2023.08, has been recently
released. Besides the usual updates of GCC, binutils, GDB, kernel
headers, and C libraries, support for AArch64 BE with musl has been
enabled, which explains why there are two new toolchains and two new
test cases.
All test cases where successfully tested:
https://gitlab.com/tpetazzoni/buildroot/-/pipelines/957304450/builds
Note that the sparcv8 uClibc toolchains are considered obsolete. They
are still available, but at some point we'll have to drop them from the
choice.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix the following build failure:
>>> toolchain-external-codescape-img-mips 2018.09-02 Copying gdbserver
Could not find gdbserver in external toolchain
Fixes:
- http://autobuild.buildroot.org/results/b0786965e0b249c8168df855682e54cfe95fa0cc
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fix the following build failure:
>>> toolchain-external-codescape-mti-mips 2018.09-02 Copying gdbserver
Could not find gdbserver in external toolchain
Fixes:
- http://autobuild.buildroot.org/results/ead304285a9cf32bf6b9dcc7fc30acece25ec680
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch allows to use an external toolchain based on gcc 13.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Call these unconditionally to make sure proper support is flagged so
proper dependencies are included in the resultant filesystem.
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The fragments provided by toolchains.bootlin.com were incorrectly
flagging toolchains as not having OpenMP support while they had it
[0]. This has been fixed in toolchains.bootlin.com, so a run of
gen-bootlin-toolchains has allowed to adjust the toolchain definitions
in Buildroot, leading to this commit.
OpenMP support needs to be flagged so the proper libraries get copied
into the resultant filesystem to avoid missing dependencies [1].
[0]: https://github.com/bootlin/toolchains-builder/issues/60
[1]: https://bugs.busybox.net/show_bug.cgi?id=15634
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Updated to gcc 12.2, gdb 12, binutils 2.39, glibc 2.36.
Upstream changed version scheme previously based on the release
date (2021.07) to a version scheme based on gcc version (12.2.rel1).
The runtime issue (Illegal instruction on some x86 host) [1] seems to
be fixed since it can't be reproduced anymore on the same host.
The x86_64 host variant prebuilt toolchain is built on RHEL7
(glibc 2.17) and is likely also be useable on OS versions like
RHEL8, Ubuntu 18.04 or later.
The AArch64 host variant prebuilt toolchain is built on Ubuntu 18.04
(glibc 2.27) is likely also be useable on OS versions like RHEL8,
Ubuntu 18.04 or later.
Use the sha256 hash that is now provided by upsteam.
[1] https://bugs.linaro.org/show_bug.cgi?id=5825#c19
[2] https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Updated to gcc 12.2, gdb 12, binutils 2.39, glibc 2.36.
Upstream changed version scheme previously based on the release
date (2021.07) to a version scheme based on gcc version (12.2.rel1).
The runtime issue (Illegal instruction on some x86 host) [1] seems to
be fixed since it can't be reproduced anymore on the same host.
The x86_64 host variant prebuilt toolchain is built on RHEL7
(glibc 2.17) and is likely also be useable on OS versions like
RHEL8, Ubuntu 18.04 or later.
The AArch64 host variant prebuilt toolchain is built on Ubuntu 18.04
(glibc 2.27) is likely also be useable on OS versions like RHEL8,
Ubuntu 18.04 or later.
Use the sha256 hash that is now provided by upsteam.
Tested with qemu_aarch64_virt_defconfig.
[1] https://bugs.linaro.org/show_bug.cgi?id=5825#c19
[2] https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Updated to gcc 12.2, gdb 12, binutils 2.39, glibc 2.36.
Upstream changed version scheme previously based on the release
date (2021.07) to a version scheme based on gcc version (12.2.rel1).
The runtime issue (Illegal instruction on some x86 host) [1] seems to
be fixed since it can't be reproduced anymore on the same host.
The x86_64 host variant prebuilt toolchain is built on RHEL7
(glibc 2.17) and is likely also be useable on OS versions like
RHEL8, Ubuntu 18.04 or later.
The AArch64 host variant prebuilt toolchain is built on Ubuntu 18.04
(glibc 2.27) is likely also be useable on OS versions like RHEL8,
Ubuntu 18.04 or later.
Use the sha256 hash that is now provided by upsteam.
Tested with qemu_arm_vexpress_defconfig.
[1] https://bugs.linaro.org/show_bug.cgi?id=5825#c19
[2] https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
"Toolchain prefix" option apparently doesn't have any help describing
it, which causes confusion when using external toolchain. Leaving this
option at default prefix name ("$(ARCH)-linux") when external toolchain
components are called with different prefix (e.g.
"$(ARCH)-unknown-linux-gnu") may cause build failure unless the prefix
symlink is already in place (e.g. when using Buildroot-generated
toolchain as external toolchain).
Describe the option to clarify.
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This toolchain doesn't support MIPS32r5 and MIPS64r5 and the toolchain
infrastructure fail to import the sysroot to staging.
Fixes: c4a62fa627
Fixes: http://autobuild.buildroot.org/results/701/701e8a5f713f7bdd1f32a4c549cdaac580e2522a/
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Since the commit [1], the utils/genrandconfig script improved the
configuration randomization used by autobuilders. Since then it can
generate a configuration that is not suitable for an external toolchain
such the "Codescape IMG GNU Linux Toolchain".
Indeed this toolchain can be selected for mips32r5 or mips64r5 while only
mips32r2 or mips64r2 are really supported. The toolchain issue will be
fixed in a followup change.
We want to catch such issue in check_unusable_toolchain function otherwise
it is detected late during the sysroot import into staging and trigger
a weird error message:
ln: failed to create symbolic link 'output/host/mips64el-buildroot-linux-gnu/sysroot//nvmedata/autobuild/instance-25/buildroot/libc.a': No such file or directory
ln: failed to create symbolic link 'output/host/mips64el-buildroot-linux-gnu/sysroot/usr//nvmedata/autobuild/instance-25/buildroot/libc.a': No such file or directory
This is similar test than for the main sysroot check but this time we have
to use the toolchain cflags to check the architecture sysroot.
If the architecture sysroot doesn't exist, the toolchain will reply with
"libc.a".
Either the toolchain is really broken or we used a wrong target
architecture variant. In the later case, the toolchain infrastructure will
print a meaningful error message.
Note: We also may get a similar issue using the toolchain-external-custom package
if a toolchain is used with a wrong target architecture variant.
Fixes:
http://autobuild.buildroot.org/results/701/701e8a5f713f7bdd1f32a4c549cdaac580e2522a/
[1] aeee90ec10
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Giulio Benetti <giulio.benetti@benettiengineering.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
This commit is the result of running
support/scripts/gen-bootlin-toolchains now that 2022.08 toolchains
have been made available.
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 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>
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>
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>
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>
