stunnel's configure unconditionally probes -fstack-clash-protection
using AX_APPEND_COMPILE_FLAGS. The probe compiles a trivial conftest.c,
which succeeds, so the flag ends up in CFLAGS. However, on ARM Thumb-1
gcc implements stack clash protection through -fstack-check=specific,
which it refuses for any real function body, so every source file fails
to build:
stunnel.c:1003:1: sorry, unimplemented: '-fstack-check=specific' for Thumb-1
Force the corresponding autoconf cache variable to "no" on Thumb-1, in
the same way cmocka already works around this gcc limitation, and
consistently with the existing -fstack-protector-strong override.
Fixes:
https://autobuild.buildroot.org/results/3d691184ba83ba4d881632f2b2bb4da5aa50f491/
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 15ccf339c9)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Remove -Werror from CFLAGS to prevent build errors due to warnings of
deprecated functions:
futility/cmd_create.c: In function ‘vb1_make_keypair’:
futility/cmd_create.c:96:9: error: ‘PEM_read_RSAPrivateKey’ is deprecated:
Since OpenSSL 3.0 [-Werror=deprecated-declarations]
96 | rsa_key = PEM_read_RSAPrivateKey(fp, NULL, NULL, NULL);
futility/cmd_create.c:155:9: error: ‘RSA_free’ is deprecated:
Since OpenSSL 3.0 [-Werror=deprecated-declarations]
155 | RSA_free(rsa_key);
futility/cmd_create.c:191:17: error: ‘PEM_read_RSA_PUBKEY’ is deprecated:
Since OpenSSL 3.0 [-Werror=deprecated-declarations]
191 | rsa_key = PEM_read_RSA_PUBKEY(fp, NULL, NULL, NULL);
futility/cmd_create.c:199:9: error: ‘RSA_get0_key’ is deprecated:
Since OpenSSL 3.0 [-Werror=deprecated-declarations]
199 | RSA_get0_key(rsa_key, NULL, NULL, &rsa_d);
cc1: all warnings being treated as errors
The oldest build error dates back to 2024 so a backport to LTS branches
should be considered.
Fixes:
https://autobuild.buildroot.net/results/375/37554c5ce784835a36f0068d9a0c1cd931212b44/https://autobuild.buildroot.net/results/1fa/1fabca11c7839d2d7ed809f30482595719a29c92/
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 4463009364)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Boost.DateTime is header-only since 1.77.0
The Boost Release Notes[0] didn't mention it but it was introduced in
the documentation of DateTime in this commit: [1]
This was bumped in buildroot in d39d8f7cee
So analog to the "header-only" move of Boost.System we have now to
gradually phase out the dependencies on this library. Ideally before
the stub is removed as it now happened for Boost.System in 1.89.0.
[0] https://www.boost.org/releases/1.77.0/
[1] 33dc6136f1
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit a235a33cfe)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
pkg-stats columns are sorted either alphabetically or numerically. This
does not make much sense for the "Latest version" column.
This commit orders the column by whether the package is up-to-date or
not.
Signed-off-by: Franciszek Stachura <fbstachura@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 95b1e8676c)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Add basic tests for openscap, ensuring that it builds and runs a minimal
command with different cryptographic backends:
- libgcrypt
- libnss
- no crypto backend
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit a304c7bf12)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
When enabling the openscap package and the libnss library _but not_
libgcrypt, the build can fail on the following error:
../src/libopenscap.so.33.1.3: undefined reference to `crapi_init'
The issue is due to the fact that the corresponding Makefile
systematically forces -DWITH_CRYPTO=gcrypt: openscap CMake
instrumentation then searches only this backend, fails to find it,
assumes that no crypto backend is available, and so does not include the
crapi_object in the final link step.
Commit 7c85f3adf4 ("package/openscap: new package") took into account
the fact that openscap isn't currently able to build if no crypto backend
is provided (see [0]), and so made sure to force libgcrypt inclusion if
libnss is not included. Since then, two fixes ([1] and [2]) have been
integrated upstream to allow building openscap with any backend.
Do not systematically enforce libgcrypt anymore through WITH_CRYPTO:
rather than testing nss presence, and falling back to libgcrypt, allow
both to be absent, and so relax the libgcrypt dependency to make it
optional as well. Bring the two upstream patches allowing openscap build
without any crypto backend. Those patches can be dropped once openscap
v1.4.5 is released.
[0] https://github.com/OpenSCAP/openscap/issues/2310
[1] d12d820a94
[2] 5b858d1786
Fixes: https://autobuild.buildroot.org/results/4c905c1b0ee384149c3d85e8f2ebf0af3a12c2ad/
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit c24ae7f2f1)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
The comment about the toolchain requirements to have Python support in
gnuradio is always displayed, even if architecture requirements are
not met and if Python is not enabled. For the latter: the option
BR2_PACKAGE_GNURADIO_PYTHON also depends on python, so it makes sense
for the Config.in comment to also depend on it.
Fixes: 7a546b87d5 ("package/python-numpy: add reverse dependency on packages using python-numpy")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit fbb9739dd8)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
BR2_PACKAGE_GNURADIO_PYTHON selects BR2_PACKAGE_PYTHON_NUMPY, so it
should inherit its dependencies, but BR2_TOOLCHAIN_GCC_AT_LEAST_9 was
forgotten in commit 8b3993178d, when
python-numpy got this gcc >= 9 dependency added.
Note that the existing BR2_HOST_GCC_AT_LEAST_9 dependency is correct:
it is there because gnuradio needs host-python-numpy at build time.
Fixes: 8b3993178d ("package/python-numpy: needs gcc >= 9")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit c6986e6d2e)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
This commit fixes 3 issues in the Config.in comment:
- It is displayed even on unsupported CPU architectures, so we add a
"depends on BR2_PACKAGE_TENSORFLOW_LITE_ARCH_SUPPORTS"
- It doesn't mention the need for a glibc toolchain even though that's
part of the dependencies
- The requirement for dynamic lib support should be part of the same
comment as the other dependencies
Fixes: fd29fee3a3 ("package/tensorflow-lite: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 101d543e38)
[raphael: resolve conflicts]
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
BR2_PACKAGE_TENSORFLOW_LITE selects BR2_PACKAGE_LIBABSEIL_CPP without
propagating its depends on BR2_PACKAGE_LIBABSEIL_CPP_ARCH_SUPPORTS,
which this commit fixes.
Note that this doesn't create any functional change: tensorflow-lite
is anyway limited to ARM, ARM64, x86 32-bit and x86 64-bit, all of
which are supported by libabseil-cpp.
Fixes: fd29fee3a3 ("package/tensorflow-lite: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit f5a2b35531)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
BR2_PACKAGE_RPI_RGB_LED_MATRIX_VIDEO_VIEWER selects
BR2_PACKAGE_FFMPEG, but without propagating its depends on, and most
notably BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS.
Fixes: e821078031 ("package/rpi-rgb-led-matrix: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 0fbbe6b681)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
libgtk3 selects at-spi2-core, so it should inherit its
!BR2_STATIC_LIBS, which this commit does.
This has been an issue since libgtk3 started using at-spi2-core
instead of atk in commit 2c3ca7bea1.
Fixes: 2c3ca7bea1 ("package/atk: remove package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 93282f76a5)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Commit 0b9efc991f ("linux: use BR2_MAKE", 2023-04-10) replaced $(MAKE)
with $(BR2_MAKE) in a number of recipes. As a consequence, the child
make is unable to discover the job server, in some cases. In those
cases, we get a warning such as:
> warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
See [1] and [2].
Falling back to single job can make build considerably longer.
This longer build time issue can be reproduced in specific
conditions. This situation happens when:
1. The top GNU Make is using a "pipe" jobserver.
This is the default when GNU Make <= 4.3 is used (and v4.3 is the
version inside the current Buildroot Docker reference image).
Make > 4.3 changed the default jobserver style to "fifo".
See [3][4]. With Make > 4.3, the issue can be reproduced by
calling "make --jobserver-style=pipe ...".
2. The root filesystem is an initramfs linked into the Kernel
(i.e. using the config BR2_TARGET_ROOTFS_INITRAMFS=y)
3. Buildroot per-package directories is used
(i.e. using the config BR2_PER_PACKAGE_DIRECTORIES=y)
4. The build is made in parallel, with 2 or more jobs. For example:
make -j$(nproc)
Overall, the issue can be reproduced with the commands:
utils/docker-run
cat >.config <<EOF
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PER_PACKAGE_DIRECTORIES=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
BR2_TARGET_ROOTFS_INITRAMFS=y
EOF
make olddefconfig
make -j$(nproc)
The Linux Kernel is built once (with a fake empty initramfs cpio
image), when build log is showing ">>> linux 7.2.6 Building". Then,
at the end of the Buildroot build, once the CPIO filesystem is
complete, it is integrated inside the Kernel with an extra "make"
invocation when the build log shows
">>> Rebuilding kernel with initramfs".
This second kernel "make" is not expected to rebuild the whole
kernel, since compiled objects from the first compilation are still
here. However, in the described conditions, the second kernel is
fully rebuilt. This is an undesired behaviour. The Make jobserver
issue adds up to that: this second full kernel is rebuilt with only
one job, which can significantly increase the build time.
Running the previous example on a host with 128 CPUs:
without this change, build takes 1h5m,
with this change, build takes 7m.
Note: using GNU Make >= 4.4 (with a fifo jobserver style by default)
or removing per-package directories no longer produces the issue.
For reference, running the example, without this change and without
per-package directories on the same host, the build takes 10 mins.
This commit improves the situation by prefixing the recipe with "+",
to inform the parent Make that $(BR2_MAKE) can deal with the job
server. This will give a chance to do jobs in parallel, in general.
Note: the pkg-generic.mk infra already has '+' for _BUILD_CMDS, which is
why other $(BR2_MAKE) invocations in linux.mk does not need this '+'.
See [5].
[1] https://www.gnu.org/software/make/manual/html_node/Error-Messages.html
[2] https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html
[3] https://www.gnu.org/software/make/manual/html_node/Options-Summary.html#index-_002d_002djobserver_002dstyle
[4] https://cgit.git.savannah.gnu.org/cgit/make.git/commit/?id=7ad2593b2d2bb5b9332f4444d8bf93ac6f958bc6
[5] 069b33a30e
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Oleg Lyovin <ovlevin@sberdevices.ru>
Cc: buildroot@buildroot.org
Signed-off-by: Laszlo Ersek <laszlo.ersek@arm.com>
[Julien: extend commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 86a56dcc17)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
python-grpcio builds its own bundled copy of abseil-cpp, which only
implements DirectMmap() with mmap2 for the o32 ABI on MIPS:
#if ... (defined(__mips__) && _MIPS_SIM == _MIPS_SIM_ABI32) || ...
With the n32 ABI, the "remaining 64-bit architectures" fallback is
selected instead, which fails to build because long is 32-bit there:
third_party/abseil-cpp/absl/base/internal/direct_mmap.h:130:39:
error: static assertion failed: Platform is not 64-bit
130 | static_assert(sizeof(unsigned long) == 8, "Platform is not 64-bit");
| ~~~~~~~~~~~~~~~~~~~~~~^~~~
third_party/abseil-cpp/absl/base/internal/direct_mmap.h:130:39:
note: the comparison reduces to '(4 == 8)'
This is the same defect fixed for libabseil-cpp in the previous patch,
but the dependency added there does not help here: python-grpcio does
not use the Buildroot abseil, it compiles the copy bundled in the
tarball.
Using the Buildroot-provided abseil instead is not an option today.
setup.py does have a GRPC_PYTHON_BUILD_SYSTEM_ABSL knob, but it is
hardcoded to the build machine paths:
if BUILD_WITH_SYSTEM_ABSL:
CORE_C_FILES = filter(
lambda x: "third_party/abseil-cpp" not in x, CORE_C_FILES
)
ABSL_INCLUDE = (os.path.join("/usr", "include"),)
[...]
if BUILD_WITH_SYSTEM_ABSL:
EXTENSION_LIBRARIES += tuple(
lib.stem[3:]
for lib in sorted(pathlib.Path("/usr").glob("lib*/libabsl_*.so"))
)
i.e. it would pick up the host headers and host libraries, so it cannot
be used when cross-compiling without patching setup.py. And even with
such a patch it would not fix this build failure, since Buildroot's
abseil has the very same limitation.
So just disable the package for the n32 ABI. The o32 and n64 ABIs are
unaffected. Note that n32 is the default ABI for BR2_mips64/BR2_mips64el,
so this affects every mips64 build that does not explicitly select n64.
For the LTS maintainers: python-grpcio gained MIPS support in commit
2bfad952c3, released in 2024.02, and the autobuilders have been hitting
this ever since, already with grpcio 1.60.0, the version shipped in
2024.02:
https://autobuild.buildroot.net/results/e6cb7f473a28af8b53e7cbb8d8a582adffdeb66e/
It is still reproduced on 2025.02.x:
https://autobuild.buildroot.net/results/9cf98bff7ce05262d6ff4221953901ae5543880e/
so a backport is needed there.
Fixes: 2bfad952c3 ("package/python-grpcio: add BR2_PACKAGE_PYTHON_GRPCIO_ARCH_SUPPORTS")
Fixes:
https://autobuild.buildroot.net/results/90405c0a3d0b2e929d5074305906e6fe3679298c/
Assisted-by: Claude:claude-opus-5
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit d4c13e96cf)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
absl::base_internal::DirectMmap() only implements mmap() via mmap2 for
the o32 ABI on MIPS:
#if ... (defined(__mips__) && _MIPS_SIM == _MIPS_SIM_ABI32) || ...
With the n32 ABI, the "remaining 64-bit architectures" fallback is
selected instead, which fails to build because long is 32-bit there:
absl/base/internal/direct_mmap.h: In function 'void* absl::lts_20260107::base_internal::DirectMmap(void*, size_t, int, int, int, off_t)':
absl/base/internal/direct_mmap.h:130:39: error: static assertion failed: Platform is not 64-bit
130 | static_assert(sizeof(unsigned long) == 8, "Platform is not 64-bit");
| ~~~~~~~~~~~~~~~~~~~~~~^~~~
absl/base/internal/direct_mmap.h:130:39: note: the comparison reduces to '(4 == 8)'
direct_mmap.h is included by absl/base/internal/low_level_alloc.cc and
absl/base/internal/poison.cc, which are always built, so the failure is
unconditional. Upstream abseil has no support for the n32 ABI, so
disable the package for that ABI.
Since n32 is the default ABI for BR2_mips64/BR2_mips64el, this affects
every mips64 build that does not explicitly select n64. The o32
(BR2_MIPS_OABI32) and n64 (BR2_MIPS_NABI64) ABIs are unaffected, and all
in-tree mips64 defconfigs use n64.
For the LTS maintainers: the ABI list in direct_mmap.h is identical in
abseil 20200225 (the version in tree when the arch dependencies were
introduced) and in the current 20260817.0, so the failure has existed
ever since mips64 was allowed. It is still reproduced on all maintained
branches, e.g.:
2026.02.x https://autobuild.buildroot.net/results/5818407a73cfd3371cd1f726a24df6ceb9afa42d/
2025.02.x https://autobuild.buildroot.net/results/5065bda3b91bdbee53559dd97af8ab5a63a1e112/
so a backport is needed there.
Fixes: ae0557403a ("package/libabseil-cpp: add BR2_PACKAGE_LIBABSEIL_CPP_ARCH_SUPPORTS")
Fixes:
https://autobuild.buildroot.net/results/f375584f3721d61238b9e43d9926e037802f6141/
Assisted-by: Claude:claude-opus-5
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 263cfb165e)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Commit 1f7efaf89f ("package/qemu: do not support x86_steamroller or
x86_core_avx2") excluded BR2_x86_steamroller from
BR2_PACKAGE_HOST_QEMU_ARCH_SUPPORTS. This is still needed, but for a
different reason than AVX, and the exclusion is incomplete.
steamroller is bdver3, and what the Qemu TCG engine cannot emulate
there is not AVX, but the Bulldozer-specific XOP, FMA4, TBM and LWP
extensions. In Qemu 11.0.0 (the version we currently package) and
11.1.1, target/i386/cpu.c has:
#define TCG_EXT3_FEATURES (CPUID_EXT3_LAHF_LM | CPUID_EXT3_SVM | \
CPUID_EXT3_CR8LEG | CPUID_EXT3_ABM | CPUID_EXT3_SSE4A | \
CPUID_EXT3_3DNOWPREFETCH | CPUID_EXT3_KERNEL_FEATURES | \
CPUID_EXT3_CMP_LEG)
CPUID_EXT3_XOP, CPUID_EXT3_FMA4, CPUID_EXT3_TBM and CPUID_EXT3_LWP are
defined in target/i386/cpu.h, but are not part of that mask, i.e. TCG
does not implement them. Binaries using those instructions therefore
die with:
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
This affects the whole Bulldozer family, not only steamroller:
bulldozer (bdver1), piledriver (bdver2) and excavator (bdver4) are
equally unsupported, but were never excluded.
Use the newly introduced BR2_X86_CPU_HAS_XOP symbol, which covers all
four variants, instead of listing BR2_x86_steamroller alone. As for
AVX512, this disables gobject-introspection and nodejs, which are the
two packages needing host-qemu in user mode.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 22c0ec4fcf)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
The AMD Bulldozer family (bdver1 to bdver4, i.e. bulldozer, piledriver,
steamroller and excavator) is the only x86 family implementing the XOP
instruction set, together with the equally Bulldozer-specific FMA4 and
LWP extensions, and TBM starting with bdver2. All of them were dropped
again with Zen.
This can be verified with:
$ gcc -march=bdver1 -Q --help=target | grep -E '\-m(xop|fma4|tbm|lwp)'
-mfma4 [enabled]
-mlwp [enabled]
-mtbm [disabled]
-mxop [enabled]
$ gcc -march=bdver2 -Q --help=target | grep -E '\-m(xop|fma4|tbm|lwp)'
-mfma4 [enabled]
-mlwp [enabled]
-mtbm [enabled]
-mxop [enabled]
with bdver3 and bdver4 behaving like bdver2.
Add a hidden BR2_X86_CPU_HAS_XOP capability symbol and select it from
those four CPU variants, so that packages which cannot cope with this
instruction set can depend on it, instead of listing the CPU variants
one by one. The first user is host-qemu, whose TCG engine does not
implement XOP.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit f91407f012)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Commit 1f7efaf89f ("package/qemu: do not support x86_steamroller or
x86_core_avx2") excluded BR2_x86_core_avx2 from
BR2_PACKAGE_HOST_QEMU_ARCH_SUPPORTS because binaries built for that CPU
variant crashed under qemu-user. This was done at the time of Qemu 4.2,
whose TCG engine did not implement AVX at all.
Since Qemu 7.2, the TCG engine implements AVX, AVX2, F16C, FMA3 and
VAES. In Qemu 11.0.0 (the version we currently package) and 11.1.1,
target/i386/cpu.c has:
#define TCG_EXT_FEATURES (... | CPUID_EXT_AVX | CPUID_EXT_F16C | \
CPUID_EXT_FMA | ...)
#define TCG_7_0_EBX_FEATURES (... | CPUID_7_0_EBX_BMI1 | \
CPUID_7_0_EBX_BMI2 | CPUID_7_0_EBX_AVX2 | ...)
which covers everything gcc generates for -march=core-avx2.
In addition, the exclusion was inconsistent: gcc's core-avx2 is a
deprecated alias for haswell, both variants select exactly the same
BR2_X86_CPU_HAS_* symbols in arch/Config.in.x86, and haswell was never
excluded. The same goes for broadwell, skylake, zen*, x86-64-v3, ...,
which all enable AVX2 and build fine on the autobuilders.
So drop the BR2_x86_core_avx2 exclusion.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 8d80efe017)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Fixes:
https://autobuild.buildroot.net/results/d43/d4364f6e3636c696471bf8cba6d308439130e53a/
In function 'MakeIv',
inlined from 'TestSymmetricAlgorithm' at AlgorithmTests.c:197:25:
AlgorithmTests.c:181:23: error: writing 32 bytes into a region of size
16 [-Werror=stringop-overflow=]
The build error occurs with gcc 15.x on some platforms, gcc 14.x is not
affected.
These defconfigs build without this patch:
BR2_x86_64=y
BR2_GCC_VERSION_14_X=y
BR2_PACKAGE_IBM_SW_TPM2=y
BR2_x86_64=y
BR2_x86_x86_64_v4=y
BR2_GCC_VERSION_14_X=y
BR2_PACKAGE_IBM_SW_TPM2=y
BR2_x86_64=y
BR2_PACKAGE_IBM_SW_TPM2=y
This gcc-15 based defconfig is broken:
BR2_x86_64=y
BR2_x86_x86_64_v4=y
BR2_PACKAGE_IBM_SW_TPM2=y
The build error is not related to the recent bump of the package from
rev183-2024-03-27 to rev183-2026-08-26 because no changes were committed
upstream to AlgorithmTests.c since rev183-2024-03-27:
https://github.com/kgoldman/ibmswtpm2/commits/master/src/AlgorithmTests.c
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit b016989c61)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Fixes build error:
In file included from client.c:14:
client.c: In function 'JNI_OnLoad':
./../../src/est/est.h:834:10: error: implicit declaration of function 'ERR_load_crypto_strings'; did you mean 'ERR_load_CRYPTO_strings'? [-Wimplicit-function-declaration]
834 | do { ERR_load_crypto_strings(); \
| ^~~~~~~~~~~~~~~~~~~~~~~
client.c:88:9: note: in expansion of macro 'est_apps_startup'
88 | est_apps_startup();
| ^~~~~~~~~~~~~~~~
./../../src/est/est.h:836:10: error: implicit declaration of function 'ENGINE_load_builtin_engines' [-Wimplicit-function-declaration]
836 | ENGINE_load_builtin_engines(); \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
client.c:88:9: note: in expansion of macro 'est_apps_startup'
88 | est_apps_startup();
| ^~~~~~~~~~~~~~~~
client.c: In function 'JNI_OnUnload':
./../../src/est/est.h:860:40: error: implicit declaration of function 'ENGINE_cleanup'; did you mean 'EVP_PBE_cleanup'? [-Wimplicit-function-declaration]
860 | OBJ_cleanup(); EVP_cleanup(); ENGINE_cleanup(); \
| ^~~~~~~~~~~~~~
client.c:101:9: note: in expansion of macro 'est_apps_shutdown'
101 | est_apps_shutdown();
| ^~~~~~~~~~~~~~~~~
./../../src/est/est.h:862:10: error: implicit declaration of function 'ERR_free_strings'; did you mean 'ERR_load_EC_strings'? [-Wimplicit-function-declaration]
862 | ERR_free_strings(); } while (0)
| ^~~~~~~~~~~~~~~~
client.c:101:9: note: in expansion of macro 'est_apps_shutdown'
101 | est_apps_shutdown();
| ^~~~~~~~~~~~~~~~~
client.c: In function 'est_client_raise_exception':
client.c:122:17: error: implicit declaration of function 'ERR_print_errors_fp' [-Wimplicit-function-declaration]
122 | ERR_print_errors_fp(stderr);
| ^~~~~~~~~~~~~~~~~~~
seen with this defconfig
BR2_PACKAGE_OPENJDK=y
BR2_PACKAGE_LIBEST=y
The failing code was added upstream on Jul, 6th, 2020:
ab998c0918
and included in version 3.2.0.
Buildroot commit 5bbb1834a4 bumped the
package to a tree including the aforementioned upstream commit on Jul
24th, 2022 so a backport to LTS branches should be considered.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 7e34cd7c7e)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
https://lists.exim.org/lurker/message/20260820.154633.91995f73.en.html
Rebased patch 0001.
Updated patch 0005, the previous version was applied upstream with
commit 497e9eb7e77ad27ae1d45281e23eefadfaa7a3bc but it did not fix all
linker errors so we sent a new patch upstream which replaces the
previous patch.
Updated hash of GPL-2.0 license file (address, name of president and
typos), a commit can not be provided from the source tree.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 8b009489f5)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Add an infrastructure test case to verify that the per-package
<PKG>_FLAT_STACKSIZE variable correctly configures the stack size in the
generated FLAT binary header.
Signed-off-by: Fengwei Tan <tfx2001@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 0bf4525045)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
The comment should be shown when !BR2_INSTALL_LIBSTDCPP is true, also
treat BR2_PACKAGE_LIBURCU_ARCH_SUPPORTS as arch dependency.
Fixes: 54f96add94 ("package/bind: security bump version to 9.20.24")
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 96ac57460f)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
No autobuilder errors were recorded, the build error can be reproduced
with this defconfig:
BR2_x86_64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_SOFTPIPE=y
BR2_PACKAGE_MESA3D_OPENGL_GLX=y
BR2_PACKAGE_MESA3D_OPENGL_EGL=y
BR2_PACKAGE_QT5=y
BR2_PACKAGE_QT5WEBENGINE=y
BR2_PACKAGE_XORG7=y
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 60dc97fcee)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Building gobject-introspection for an x86 CPU variant with AVX512 fails
when g-ir-scanner runs the freshly built target binaries under
qemu-user:
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
The Qemu TCG engine implements AVX, AVX2, F16C, FMA3 and VAES since Qemu
7.2, but it does not implement the AVX512 instruction set at all [0].
Therefore no -cpu value passed through
BR2_PACKAGE_HOST_QEMU_USER_MODE_ARGS can make such binaries run, and
user-mode emulation is simply not possible for these CPU variants.
Mark those CPUs as unsupported by host-qemu, the same way it is already
done for x86_steamroller and x86_core_avx2. This relies on the existing
BR2_X86_CPU_HAS_AVX512 symbol, so all AVX512 capable variants are
covered, and it disables gobject-introspection and nodejs, which are the
two packages needing host-qemu in user mode.
[0] https://gitlab.com/qemu-project/qemu/-/issues/2878
Fixes:
https://autobuild.buildroot.org/results/7ed7f9c36dae1ddb965a0f0021db6cd319927b47/
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit c2bd6148c6)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
