The "arches" dict lists the architectures for which Bootlin toolchains
are available, along with the corresponding Buildroot conditions for
those architecture variants.
However, there is nothing that checks that such architectures really
have Bootlin toolchains available. Even if no toolchain is available,
the architecture is considered as support, and will be listed in the
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARCH_SUPPORTS option, making menuconfig
believe that some Bootlin toolchain is available for the selected
architecture variant.
This is currently the case with the "mips64" architecture (as
identified by the Bootlin toolchains project). Such toolchains have
been made obsolete in toolchains.bootlin.com and replaced by the
mips64-n32 toolchains. But "mips64" is still listed in "arches",
causing this architecture to be considered as having Bootlin
toolchains available.
To avoid this to happen in the future, this commit adds a check that
verifies that an architecture listed in "arches" really has at least
one toolchain available.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(cherry picked from commit 3c11e6f3c8)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
(cherry picked from commit 80a24d0965)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
We now support both MMU-enabled and MMU-less RISC-V 64-bit
configurations. However, the Bootlin toolchain for RISC-V 64-bit only
supports MMU-enabled configurations, but the current logic in
toolchain/toolchain-external/toolchain-external-bootlin/ does not take
this into account, and allows selecting the Booltin toolchain for
MMU-less RISC-V 64-bit configurations.
To fix this, the gen-bootlin-toolchains script is modified to add the
BR2_USE_MMU dependency to the description of the RISC-V 64-bit
toolchain.
However, the BR2_USE_MMU dependency was also added for glibc and musl
toolchains unconditionally, so to avoid duplicating the dependency, we
now only add it only if not already present in the list of
dependencies for this toolchain.
This will allow to fix:
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>
(cherry picked from commit 1f4bba5967)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Pass TARGET_LDFLAGS (which will contain -static) through LIBS (as
LDFLAGS is not supported) to fix the following static build failure
(e.g. with musl):
/home/autobuild/autobuild/instance-15/output-1/host/lib/gcc/microblazeel-buildroot-linux-musl/10.3.0/../../../../microblazeel-buildroot-linux-musl/bin/ld: /home/autobuild/autobuild/instance-15/output-1/host/lib/gcc/microblazeel-buildroot-linux-musl/10.3.0/libgcc.a(unwind-dw2.o): in function `__gthread_once':
/home/autobuild/autobuild/instance-15/output-1/build/host-gcc-final-10.3.0/build/microblazeel-buildroot-linux-musl/libgcc/gthr-default.h:700: undefined reference to `pthread_once'
While at it, also pass TARGET_CFLAGS through LIBS as suggested by Thomas
Petazzoni
Fixes:
- http://autobuild.buildroot.org/results/5ea9b1b976aecc401e0aff21eef3e31c8ed17181
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Arnout: remove CPPFLAGS, already in CFLAGS]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(cherry picked from commit c5ffe830f3)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following build failure with BR2_PACKAGE_LIBMEDIAART_BACKEND_QT
raised since bump to version 1.9.5 in commit
3db4d486d6:
/home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/sparc-buildroot-linux-uclibc/10.3.0/../../../../sparc-buildroot-linux-uclibc/bin/ld: libmediaart/libmediaart-2.0.so.0.905.0.p/extractqt.cpp.o: in function `std::__atomic_base<int>::operator--()':
/home/buildroot/autobuild/instance-0/output-1/host/opt/ext-toolchain/sparc-buildroot-linux-uclibc/include/c++/10.3.0/bits/atomic_base.h:334: undefined reference to `__atomic_fetch_sub_4'
Fixes:
- http://autobuild.buildroot.org/results/39aa4ecd37de774e06f67a6e1c4495dc1f0917b4
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(cherry picked from commit bd396de5ec)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix strndup detection as already done for strdup in commit
f9287b263f to avoid the following build
failure raised since bump to version 5.6.5 in commit
736932c715:
In file included from /nvmedata/autobuild/instance-0/output-1/host/mipsel-buildroot-linux-gnu/sysroot/usr/include/string.h:630:0,
from append.c:34:
dmalloc.h:396:7: error: expected identifier or '(' before '__extension__'
char *strndup(const char *string, const DMALLOC_SIZE max_len);
^
Fixes:
- http://autobuild.buildroot.org/results/2164dac43e2607a3570e8f98957a70f579d06cd3
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit dcf695206e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Move libzstd.pc in ZSTD_BUILD_LIBS so it will be suffixed by -nomt
without threads. As a result, libzstd.pc will not contain -pthread in
Libs.Private which will avoid the following static build failure with
zchunk) raised since commit 0f0e913f10:
/home/buildroot/autobuild/instance-2/output-1/host/bin/aarch64_be-buildroot-linux-uclibc-gcc -o src/unzck src/unzck.p/unzck.c.o src/unzck.p/util_common.c.o -Wl,--as-needed -Wl,--no-undefined -static -Wl,--start-group src/lib/libzck.a -largp /home/buildroot/autobuild/instance-2/output-1/host/aarch64_be-buildroot-linux-uclibc/sysroot/usr/lib/libzstd.a -pthread /home/buildroot/autobuild/instance-2/output-1/host/aarch64_be-buildroot-linux-uclibc/sysroot/usr/lib/libssl.a /home/buildroot/autobuild/instance-2/output-1/host/aarch64_be-buildroot-linux-uclibc/sysroot/usr/lib/libcrypto.a -Wl,--end-group
/home/buildroot/autobuild/instance-2/output-1/host/lib/gcc/aarch64_be-buildroot-linux-uclibc/10.3.0/../../../../aarch64_be-buildroot-linux-uclibc/bin/ld: cannot find -lpthread
Fixes:
- http://autobuild.buildroot.org/results/481d1979920daaecac48dec763151e124651740f
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 253a951c4f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
libnetconf2 doesn't build with libressl which doesn't provide
X509_STORE_CTX_get1_certs resulting in the following build failure with
netopeer2:
[100%] Linking C executable netopeer2-server
/home/buildroot/autobuild/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/microblaze-buildroot-linux-gnu/11.2.0/../../../../microblaze-buildroot-linux-gnu/bin/ld: /home/buildroot/autobuild/instance-3/output-1/host/microblaze-buildroot-linux-gnu/sysroot/usr/lib/libnetconf2.so: undefined reference to `X509_STORE_CTX_get1_certs'
Fixes:
- http://autobuild.buildroot.org/results/7f9a114a477e859dfbc62a53ab66c58eddb2318b
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit e6904fdd7e)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is not enabled when ARMv8
target hardware is combined with 32-bit software. That is because ARMv7
(32-bit) toolchain is only enabled for BR2_ARM_CPU_ARMV7A which is
mutually exclusive with BR2_ARM_CPU_ARMV8A.
Use ARMv7 toolchain for 32-bit software.
Cc: James Hilliard <james.hilliard1@gmail.com>
Reported-by: Oscar Gomez Fuente <oscargomezf@gmail.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 350772148f)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix libexecinfo workaround to avoid the following ffmpeg build failure
with BR2_PACKAGE_RPI_USERLAND raised on uclibc and musl since commit
bc4cc27705:
/home/giuliobenetti/autobuild/run/instance-3/output-1/host/bin/arm-linux-gcc --sysroot=/home/giuliobenetti/autobuild/run/instance-3/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot -mcpu=arm926ej-s -Wl,--as-needed -Wl,-z,noexecstack -o /tmp/ffconf.5K0cMIh3/test /tmp/ffconf.5K0cMIh3/test.o -lmmal_core -lmmal_util -lmmal_vc_client -lbcm_host -latomic
/home/giuliobenetti/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/10.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: /home/giuliobenetti/autobuild/run/instance-3/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libvcos.so: undefined reference to `backtrace_symbols'
[...]
ERROR: mmal not found
Fixes:
- http://autobuild.buildroot.org/results/64d21872d25fef35b72106133ed2aed300f52f2f
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 66d7d3bec3)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Without CA bundle curl can not verify the remote peer and work with https.
This is fixed by adding a config option pointing to the default location
for CA bundle in buildroot. Alternatives like OpenSSL and MbedTLS use the
same path, however the wolfSSL build options for libcurl did not include
this path until now.
Signed-off-by: Dimitar Tomov <dimi@tpm.dev>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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>
The Config.in options created for each toolchain were properly taking
into account the !BR2_STATIC_LIBS dependency of glibc
toolchains. However, this dependency was not taken into account into
the main BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARCH_SUPPORTS
option. Consequently, if an architecture is only supported by glibc,
but BR2_STATIC_LIBS is enabled, the main "Bootlin toolchain" option
was visible... but with no selectable toolchain.
We fix this by making sure that
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARCH_SUPPORTS is only true for all
architectures supported, taking into account the fact that some
architectures can only be supported if !BR2_STATIC_LIBS, when the only
available C library is glibc.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Following commit
e59b3acc36 ("toolchain/glibc: Restrict
ppc64le support to power8"), when selecting ppc64le as the
architecture, it is possible to end up with a selection for which no C
library is provided.
Indeed:
- glibc only supports Power8
- uclibc has no support for ppc64le at all
- musl only supports ppc64le processors that have Altivec support
Therefore, this commit adds "depends on !BR2_powerpc64le" to those
PowerPC architecture variants for which no C library support exists.
Fixes:
http://autobuild.buildroot.net/results/3f6fb1c2d5648e78f7856bdea3171b5a89dfa2f9/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
mono unconditionally uses pthread_attr_get_np and so needs NTPL since
version 4.0.1.43 and
748fefa1d7:
mono-threads-linux.c: In function 'mono_threads_platform_get_stack_bounds':
mono-threads-linux.c:26:15: error: implicit declaration of function 'pthread_getattr_np'; did you mean 'pthread_attr_init'? [-Werror=implicit-function-declaration]
26 | res = pthread_getattr_np (pthread_self (), &attr);
| ^~~~~~~~~~~~~~~~~~
| pthread_attr_init
Fixes:
- http://autobuild.buildroot.org/results/6534ee4ae699c17ee98f6f89a8a1212936e04481
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Fix the following build failure without a working Fortran compiler:
CMake Error at /nvmedata/autobuild/instance-17/output-1/host/share/cmake-3.18/Modules/CMakeTestFortranCompiler.cmake:51 (message):
The Fortran compiler
"/usr/bin/f95"
is not able to compile a simple test program.
Fixes:
- http://autobuild.buildroot.org/results/37f3f40ee39739b5e557d634b71a448762107a4b
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
gensio needs atomic since bump to version 2.0.1 in commit
0f8d4a6ecd and
5528267b54:
/nvmedata/autobuild/instance-7/output-1/per-package/gensio/host/bin/../lib/gcc/arc-buildroot-linux-uclibc/11.3.0/../../../../arc-buildroot-linux-uclibc/bin/ld: ../lib/.libs/libgensio.a(gensio_osops.o): in function `gensio_addr_dup':
gensio_osops.c:(.text+0x1558): undefined reference to `__atomic_fetch_add_4'
Fixes:
- http://autobuild.buildroot.org/results/229e4bd1ba1787953899875ab56721c9609f035a
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Fix the following musl build failure raised with pam and libressl:
auth-pam.c: In function 'pam_server':
auth-pam.c:894:23: error: 'PATH_MAX' undeclared (first use in this function); did you mean 'AF_MAX'?
894 | char ac_file_name[PATH_MAX];
| ^~~~~~~~
| AF_MAX
auth-pam.c:894:23: note: each undeclared identifier is reported only once for each function it appears in
auth-pam.c:894:10: warning: unused variable 'ac_file_name' [-Wunused-variable]
894 | char ac_file_name[PATH_MAX];
| ^~~~~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/c8834fa5ddcac6fd22fc9406e10221e64cdb8856
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
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>
