Buildroot commit 7f48325de6 bumped the
asterisk package from 22.9.0 to 22.10.1.
This bump includes upstream commit
5d543ad80c
which bumped the bundled pjsip package to 2.17.
To allow offline builds we download the pjsip tarball so we need to keep
the version numbers in sync.
The autobuilders logs show a download process:
https://autobuild.buildroot.net/results/400/400e53158f11926446c11d22681eb8a9430caf1d/build-end.log
checking for embedded pjproject (may have to download)... configuring
[pjproject] Downloading https://raw.githubusercontent.com/asterisk/third-party/master/pjproject/2.17/pjproject-2.17.tar.bz2 to
/home/autobuild/autobuild/instance-3/dl/asterisk/pjproject-2.17.tar.bz2
[pjproject] Verifying /home/autobuild/autobuild/instance-3/dl/asterisk/pjproject-2.17.tar.bz2
where the tarball was once stored in the configured download directory:
--with-download-cache=$(ASTERISK_DL_DIR)
to be used during later autobuilder runs.
Fixes: 7f48325de6 ("package/asterisk: security bump to 22.10.1")
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
[Thomas: add comment in .mk file]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 96a2337bd4)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Fixes: CVE-2026-18321:
https://nvd.nist.gov/vuln/detail/cve-2026-18321
- bump version to 1.2.5 (for details see [1])
- rebased 0001-wscript-remove-checks-for-bsd-string.h-fixes-host-co.patch
- rebased 0002-disable-PIE-support.patch
- removed 0003-ntpd-refclock_gpsd.c-Add-missing-time.h-for-strptim.patch
(from upstream [2])
- moved 0004-refclock_gpsd-add-build-fix-for-gcc-14.x.patch to
0003-refclock_gpsd-add-build-fix-for-gcc-14.x.patch, rebased and enhanced
as the original conflicts with upstream commit 5505260c ("Fix redefined
_XOPEN_SOURCE warning in refclock_gpsd.c") [3] and leads to the following
compile failure:
../../ntpd/refclock_gpsd.c:113:21: error: operator ‘<’ has no left operand
113 | #if _XOPEN_SOURCE < 700
| ^
[1] https://lists.ntpsec.org/pipermail/devel/2026-July/011029.html
[2] 5137c155d8
[3] 5505260cd1
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
[Julien: mark commit as "security bump"]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 1caeb632a6)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Buildroot commit [1] (package/mrouted: fix invalid daemon path in
S41mrouted) removed script execution permission but forgot to remove
the corresponding .checkpackage entry.
check-package is reporting the error:
package/mrouted/S41mrouted:0: NotExecutable was expected to fail, did you fix the file and forget to update /builds/buildroot.org/buildroot/.checkpackageignore?
This commit fixes the issue by removing the entry.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/16661195972
[1] d8f408b1f1
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e2b81003a4)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
S41mrouted hard-coded /sbin/mrouted, but mrouted has always installed
to /usr/sbin/mrouted. This went unnoticed with BR2_ROOTFS_MERGED_USR=y,
but the daemon fails to start without it.
Also drop the script's executable bit to match other sysv init
scripts that do not set it.
Introduced in c25115daf2
(package/mrouted: add sysv init script).
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit d8f408b1f1)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
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>
BR2_PACKAGE_WPEWEBKIT_MULTIMEDIA selects BR2_PACKAGE_GST1_LIBAV, which
depends on BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS, but doesn't propagate
this dependency. In practice, there is no issue, as webkitgtk is only
available on a subset of CPU architectures, while
BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS makes ffmpeg available on pretty much
all CPU architectures, except Cortex-M, m68k coldfire, and some
specific cases of OpenRISC, which are not supported by webkitgtk.
But for the sake of having correct dependency propagation, let's fix
this.
The other packages selected by BR2_PACKAGE_WPEWEBKIT_MULTIMEDIA have
dependencies that are already handled at the top-level
BR2_PACKAGE_WPEWEBKIT option.
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
CC: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Adrian Perez de Castro <aperez@igalia.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 251a80dd9d)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
In commit
0e2c958e05 ("package/libseccomp: bump to
version 2.5.3"), the kernel headers dependency of seccomp was bumped
from 3.12 to 3.17, but BR2_PACKAGE_WEBKITGTK_SANDBOX, which is a
reverse dependency of BR2_PACKAGE_LIBSECCOMP was forgotten.
This commit fixes this inconsistency.
Fixes: 0e2c958e05 ("package/libseccomp: bump to version 2.5.3")
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
CC: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 5279b2303c)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
The 0002-Update-linker-flags.patch assumes that the qemu-xen files are included
in the xen source tree. However, if BR2_PACKAGE_XEN_TOOLS is not enabled, the
qemu-xen dependency will not be handled and the patch will fail to apply with
the following error.
Fixes: build error below
Applying 0002-Update-linker-flags.patch using patch:
patching file tools/Makefile
Hunk #1 succeeded at 36 (offset -1 lines).
Hunk #2 succeeded at 185 (offset -8 lines).
can't find file to patch at input line 76
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/tools/qemu-xen/include/hw/xen/xen_native.h b/tools/qemu-xen/include/hw/xen/xen_native.h
|index 6bcc83ba..2590904e 100644
|--- a/tools/qemu-xen/include/hw/xen/xen_native.h
|+++ b/tools/qemu-xen/include/hw/xen/xen_native.h
--------------------------
No file to patch. Skipping patch.
1 out of 1 hunk ignored
make: *** [package/pkg-generic.mk:239: output/build/xen-4.21.1/.stamp_patched] Error 1
To avoid making BR2_PACKAGE_XEN_TOOLS a required option, fix the
0002-Update-linker-flags.patch so that modifying source from the qemu-xen
package is no longer included.
Instead of patching qemu-xen, a better solution is undefining the
__XEN_INTERFACE_VERSION__ from the qemu-xen package.
To test:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y
BR2_PACKAGE_XEN=y
# BR2_PACKAGE_XEN_TOOLS is not set
Signed-off-by: Neal Frager <neal.frager@amd.com>
Tested-by: Matt Weber <matt@thewebers.ws>
Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit f63e572432)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
BR2_PACKAGE_GLSLSANDBOX_PLAYER_SCRIPTS needs the full blown version of
bash and coreutils, so it selects BR2_PACKAGE_BUSYBOX_SHOW_OTHERS, but
it does so only if BR2_PACKAGE_BUSYBOX=y. Which kind of makes sense,
but is not aligned with the vast majority of other places where
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS is selected, where
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS is selected unconditionally. Harmonize
this with other packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 22540e0d41)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
BR2_PACKAGE_XEN_TOOLS needs the full blown version of bash and
coreutils, so it selects BR2_PACKAGE_BUSYBOX_SHOW_OTHERS, but it does
so only if BR2_PACKAGE_BUSYBOX=y. Which kind of makes sense, but is
not aligned with the vast majority of other places where
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS is selected, where
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS is selected unconditionally. Harmonize
this with other packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e62e06b19d)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
ndctl selects kmod and keyutils, both of which depend on
!BR2_STATIC_LIBS, but this dependency was not propagated into ndctl
when the package was introduced. This commit fixes this issue.
Fixes: 039c1ae13e ("package/ndctl: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 6dad789282)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
The Config.in comment has the correct dependency on
!BR2_TOOLCHAIN_HAS_THREADS, but that was not reflected in the comment
text itself.
Fixes: 039c1ae13e ("package/ndctl: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 3472fd59af)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
BR2_PACKAGE_STRONGSWAN_BOTAN selects BR2_PACKAGE_BOTAN, but since
commit 10a70b1af6, botan needs gcc 11,
which was not propagated to strongswan's botan option. This commit
fixes this issue.
Fixes: 10a70b1af6 ("package/botan: needs gcc >= 11")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit b56072c126)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
gerbera selects BR2_PACKAGE_ICU, which depends on !BR2_BINFMT_FLAT,
but this dependency was not propagated to gerbera. In practice this is
not an issue because gerbera depends on BR2_USE_MMU, and only noMMU
platforms can use BR2_BINFMT_FLAT. But for the sake of completeness,
let's propagate this dependency.
Note: in the Config.in comment, we handle it like an architecture
dependency, like is done in package/icu/Config.in.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 6b716763e9)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Since the bump of libabseil-cpp in commit
76241e89e1, it requires gcc 10. As part
of this commit, the protobuf package was updated, but not its reverse
dependency netdata. This commit fixes this issue.
Fixes: 76241e89e1 ("package/libabseil-cpp: bump to version 20260817.0")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e91ffb1afb)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
BR2_PACKAGE_SYSPROF selects BR2_PACKAGE_LIBDEX but did not propagate:
depends on BR2_TOOLCHAIN_HAS_UCONTEXT || \
BR2_PACKAGE_LIBUCONTEXT_ARCH_SUPPORTS
from libdex. This commit fixes this missing dependency. In terms of
Config.in comment, we do the same as what libdex is doing: handle it
as a toolchain dependency (rather than an architecture dependency).
This was missed in commit a73ef093f7,
which added the ucontext related dependency to libdex, without
propagating it to sysprof.
Fixes: a73ef093f7 ("package/libdex: needs ucontext")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit cd5eab10fe)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
BR2_PACKAGE_RPI_RGB_LED_MATRIX_IMAGE_VIEWER selects
BR2_PACKAGE_GRAPHICSMAGICK, but did not propagate its BR2_USE_MMU
dependency. This issue exists since the package was introduced in
commit e821078031.
It fixes the following Kconfig warning:
WARNING: unmet direct dependencies detected for BR2_PACKAGE_GRAPHICSMAGICK
Depends on [n]: BR2_USE_MMU [=n] && BR2_TOOLCHAIN_HAS_THREADS [=y]
Selected by [y]:
- BR2_PACKAGE_RPI_RGB_LED_MATRIX_IMAGE_VIEWER [=y] && BR2_PACKAGE_RPI_RGB_LED_MATRIX [=y]
which occurs when you configure an ARM noMMU FDPIC toolchain (because
we have noMMU, but shared libraries, so rpi-rgb-led-matrix can be
enabled).
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 e67b301f53)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
There's recently been autobuilder failures on
toolchain-external-bootlin, but I wasn't getting notified in the daily
autobuilder e-mail for those failures, which sounded odd as DEVELOPERS
contains:
N: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[...]
F: toolchain/
And indeed, testing:
$ ./utils/get-developers -p toolchain-external-bootlin
returned nothing.
Turns out that the regexp FIND_INFRA_IN_PATCH and FIND_INFRA_IN_MK
used to find the package infrastructure, and ultimately decide if a
given .mk file contains a package, was a bit too strict:
"^\+\$\(eval \$\((host-)?([^-]*)-package\)\)$"
This would only allow packages named <something>-package or
host-<something>-package, but the <something> should not contain any
dash ("-"). So this works fine for cmake-package,
host-autotools-package, but not for toolchain-external-package where
<something> is toolchain-external and it contains a dash.
We fix this by relaxing the regexp a bit and allowing any character in
<something>. Consider the rest of the regexp that expects $(eval
$(<host>-<something>-package)), it seems highly unlikely to match
anything else but the line we're interested in.
With this fix:
$ ./utils/get-developers -p toolchain-external-bootlin
Giulio Benetti <giulio.benetti@benettiengineering.com>
Romain Naour <romain.naour@gmail.com>
Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This issue has existed since the toolchain-external-package
infrastructure had been added.
Fixes: 1c99d70e52 ("toolchain-external: introduce toolchain-external-package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 592d5c517e)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Building zabbix without libcurl enabled would lead to the following
error:
/usr/bin/ld: .../src/libs/zbxxml/xml.c:515:(.text+0x1c64): undefined reference to `zbx_vector_str_append'
This issue has been addressed in the upstream commit [1] and backported
as a patch in Buildroot.
For more information see the upstream issue [2].
This error is reproducible with the following defconfig:
cat >.config <<EOF
BR2_arm=y
BR2_cortex_a7=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_PHP=y
BR2_PACKAGE_ZABBIX=y
BR2_PACKAGE_ZABBIX_SERVER=y
BR2_PACKAGE_ZABBIX_SERVER_COPY_FRONTEND=y
EOF
make oldefconfig
make zabbix
[1] https://git.zabbix.com/projects/ZBX/repos/zabbix/commits/e8333ca2128
[2] https://support.zabbix.com/browse/ZBX-27635
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 489aefc22a)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Zabbix 7.2 is EOL since December 2025 [1]
For more info on the version bump, see:
- https://www.zabbix.com/rn/rn7.2.14
- https://www.zabbix.com/rn/rn7.2.15
This fixes the following vulnerabilties:
- CVE-2026-23920:
Host and event action script input is validated with a regex (set by
the administrator), but the validation runs in multiline mode. If ^
and $ anchors are used in user input validation, an injected newline
lets authenticated users bypass the check and inject shell commands.
https://www.cve.org/CVERecord?id=CVE-2026-23920
- CVE-2026-23921:
A low privilege Zabbix user with API access can exploit a blind SQL
injection vulnerability in include/classes/api/CApiService.php to
execute arbitrary SQL selects via the sortfield parameter. Although
query results are not returned directly, an attacker can exfiltrate
arbitrary database data through time-based techniques, potentially
leading to session identifier disclosure and administrator account
compromise.
https://www.cve.org/CVERecord?id=CVE-2026-23921
[1] https://endoflife.date/zabbix
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 055a1e249c)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
check-package reports six warnings on S60lldpd: indentation with
spaces, no DAEMON variable, and shellcheck complaints.
The script also masks failures, the exit status of
"[ $? = 0 ] && echo OK || echo FAIL" is the one of echo, so start and
stop always return success. Stopping does not wait for the daemon to
exit either, so a restart can race the instance on its way out.
Rewrite it after package/busybox/S01syslogd, as the manual asks. lldpd
daemonizes and writes the PID file itself, but does not remove it on
exit, so pass the PID file to both start-stop-daemon and the daemon and
drop the stale file once the process is gone. Also pick up arguments
from /etc/default/lldpd and add the customary reload alias.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
[Julien: remove .checkpackageignore entry to fix check-package error]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 2fd1f6b629)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
In commit 203725a46b ("package/clamav:
bump version to 1.0.1"), select BR2_PACKAGE_JSON_C was added to
BR2_PACKAGE_CLAMAV without propagating the BR2_TOOLCHAIN_HAS_SYNC_4
dependency from BR2_PACKAGE_JSON_C.
Since at the same time a dependency on
BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS was added to clamav and
Rust is not supported on the few architectures that don't have 4-byte
sync intrinsics, this has basically no effect, but ensure a correct
propagation of dependencies.
Fixes: 203725a46b ("package/clamav: bump version to 1.0.1")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 39b840beef)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_FALCOSECURITY_LIBS selects BR2_PACKAGE_HOST_GRPC and
BR2_PACKAGE_HOST_PROTOBUF, neither of which exists. These selects are
anyway not needed, so drop them.
Fixes: a15e35c4eb ("falcosecurity-libs: add new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 7f5bb493e2)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_WEBKITGTK_MULTIMEDIA selects BR2_PACKAGE_GST1_LIBAV, which
depends on BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS, but doesn't propagate
this dependency. In practice, there is no issue, as webkitgtk is only
available on a subset of CPU architectures, while
BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS makes ffmpeg available on pretty much
all CPU architectures, except Cortex-M, m68k coldfire, and some
specific cases of OpenRISC, which are not supported by webkitgtk.
But for the sake of having correct dependency propagation, let's fix
this.
The other packages selected by BR2_PACKAGE_WEBKITGTK_MULTIMEDIA have
dependencies that are already handled at the top-level
BR2_PACKAGE_WEBKITGTK option.
Fixes: e6e549b9e4 ("ffmpeg: add BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit da90655637)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
In commit
0e2c958e05 ("package/libseccomp: bump to
version 2.5.3"), the kernel headers dependency of seccomp was bumped
from 3.12 to 3.17, but BR2_PACKAGE_WEBKITGTK_SANDBOX, which is a
reverse dependency of BR2_PACKAGE_LIBSECCOMP was forgotten.
This commit fixes this inconsistency.
Fixes: 0e2c958e05 ("package/libseccomp: bump to version 2.5.3")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit ef92929504)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_LIBSSH_OPENSSL unconditionnally selects
BR2_PACKAGE_LIBOPENSSL_ENGINES even though libressl is also supported
as an OpenSSL provider (and BR2_PACKAGE_LIBOPENSSL_ENGINES doesn't
make sense for libressl).
This causes the following Kconfig warning:
WARNING: unmet direct dependencies detected for BR2_PACKAGE_LIBOPENSSL_ENGINES
Depends on [n]: <choice> && BR2_PACKAGE_LIBOPENSSL [=n]
Selected by [y]:
- BR2_PACKAGE_LIBSSH_OPENSSL [=y] && <choice> && BR2_PACKAGE_OPENSSL [=y]
We checked that libssh, with OpenSSL support and libressl selected as
an OpenSSL provider works fine, using the following defconfig:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y
BR2_PACKAGE_LIBSSH=y
BR2_PACKAGE_LIBSSH_SERVER=y
BR2_PACKAGE_LIBRESSL=y
Fixes: 62103be918 ("package/libssh: select BR2_PACKAGE_LIBOPENSSL_ENGINES")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit f7fe354ada)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_QT5CINEX selects BR2_PACKAGE_QT5BASE_PNG,
BR2_PACKAGE_QT5BASE_WIDGETS and BR2_PACKAGE_QT5BASE_EGLFS, which are
all sub-options of BR2_PACKAGE_QT5BASE_GUI, but we don't explicitly
selects BR2_PACKAGE_QT5BASE_GUI.
It turns out that things work because the package selects
BR2_PACKAGE_QT5GRAPHICALEFFECTS, which selects
BR2_PACKAGE_QT5DECLARATIVE_QUICK, which selects
BR2_PACKAGE_QT5BASE_GUI, but that is rather non-obvious, and it makes
more sense for BR2_PACKAGE_QT5CINEX to directly select
BR2_PACKAGE_QT5BASE_GUI if it also selects sub-options of it.
No functional change.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit f077ba9e67)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
- BR2_PACKAGE_IVI_HOMESCREEN_AUDIO_PLAYERS selects gstreamer1, which
has a depends on BR2_USE_MMU, but does not propagate it
- BR2_PACKAGE_IVI_HOMESCREEN_FLUTTER_SECURE_STORAGE_PLUGIN selects
libsecret, which has a depends on BR2_USE_MMU, but does not propagate
it
In practice there is no problem since ivi-homescreen depends on glibc,
and glibc doesn't support any noMMU architecture. But just by walking
the chain of option dependencies, this is not something that is
theoretically guaranteed (making automated verification of
dependencies difficult).
The other "depends on" from gstreamer1 and libsecret, BR2_USE_WCHAR
and BR2_TOOLCHAIN_HAS_THREADS are on the other hand already handled by
the top-level BR2_PACKAGE_IVI_HOMESCREEN option, so there is no
ambiguity.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 90aeea08bb)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_PULSEVIEW selects BR2_PACKAGE_QT5BASE_PNG and
BR2_PACKAGE_QT5BASE_WIDGETS, which both depend on
BR2_PACKAGE_QT5BASE_GUI. It ends working because we also select
BR2_PACKAGE_QT5SVG, which selects BR2_PACKAGE_QT5BASE_GUI, so there is
no bug, but it's bit inconsistent to select sub-options that have a
"depends on" without selecting the option they depend on.
This not a bug fix, it has no functional implication.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit aff091c39d)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
pocketpy enables thread support by default (PK_ENABLE_THREADS=ON) and
then requires Threads from cmake, which fails on toolchains without
thread support:
CMake Error at /usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find Threads (missing: Threads_FOUND)
Thread support is optional, so enable it only when the toolchain
provides threads.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 376daf3dd0)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The definition of BR2_PACKAGE_KODI_ARCH_SUPPORTS is incorrect, it
goes like this:
bool
default y if BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS
default y if BR2_PACKAGE_HOST_OPENJDK_BIN_ARCH_SUPPORTS
so it means it would be "y" if either
BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS *OR*
BR2_PACKAGE_HOST_OPENJDK_BIN_ARCH_SUPPORTS is true. While clearly what
we need is for both to be true: ffmpeg should be available for the
target architecture, and openjdk should be available for the host
architecture.
One option was to change to:
bool
default y if BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS && BR2_PACKAGE_HOST_OPENJDK_BIN_ARCH_SUPPORTS
Or:
bool
default y if BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS
depends on BR2_PACKAGE_HOST_OPENJDK_BIN_ARCH_SUPPORTS
But we preferred:
bool
default y
depends on BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS
depends on BR2_PACKAGE_HOST_OPENJDK_BIN_ARCH_SUPPORTS
Fixes: b6a2f49429 ("package/kodi: depend on host-openjdk-bin instead of selecting BR2_NEEDS_HOST_JAVA")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 00e83bc24d)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Even though kodi itself has architecture dependencies (expressed
through BR2_PACKAGE_KODI_ARCH_SUPPORTS, the option
BR2_PACKAGE_KODI_MYSQL selects BR2_PACKAGE_MARIADB, which has its own
architecture dependencies as well. Make sure to propagate those to
BR2_PACKAGE_KODI_MYSQL, which doesn't require adding a Config.in
comment as these are purely architecture dependencies.
We haven't replicate all dependencies of BR2_PACKAGE_MARIADB because
all the others are covered by the top-level BR2_PACKAGE_KODI, and
propagating them would require adding a Config.in comment for
BR2_PACKAGE_KODI_MYSQL.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 16e3d628bd)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Since hidapi was introduced in commit
6267f34afd, it forgot to propagate some
dependencies of libgudev (which existed back then). Initially libgudev
was only needed when BR2_INIT_SYSTEMD=y, but still the dependencies
were not propagated for the systemd case.
Anyway, since e739dd5a11, libgudev is a
mandatory dependency of hidapi, independently from the selected init
system.
We make sure to propagate all dependencies of libgudev to hidapi, and
propagate them to the reverse dependencies of hidapi.
Fixes: 6267f34afd ("hidapi: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 74def2cdd4)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_ARGP_STANDALONE is defined as follows:
config BR2_PACKAGE_ARGP_STANDALONE
depends on !BR2_TOOLCHAIN_USES_GLIBC
Some packages did:
select BR2_PACKAGE_ARGP_STANDALONE if !BR2_TOOLCHAIN_USES_GLIBC
while a number of others did:
select BR2_PACKAGE_ARGP_STANDALONE if BR2_TOOLCHAIN_USES_UCLIBC || BR2_TOOLCHAIN_USES_MUSL
This commit harmonizes the situation, by settling on the first
solution ("if !BR2_TOOLCHAIN_USES_GLIBC") as it matches how
BR2_PACKAGE_ARGP_STANDALONE is defined in the first place.
No functional change.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 1799bf3680)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_INTEL_VPL_GPU_RT selects BR2_PACKAGE_INTEL_MEDIADRIVER but
did not propagate "depends on BR2_TOOLCHAIN_GCC_AT_LEAST_8". This
commit fixes this issue, which was introduced in commit
ac65841def, when onevpl-intel-gpu was
introduced (it was later renamed to intel-vpl-gpu-rt).
Fixes: ac65841def ("package/onevpl-intel-gpu: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 876023bc5a)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_INTEL_MEDIASDK selects BR2_PACKAGE_INTEL_MEDIADRIVER but
forgets to propagate the "depends on BR2_TOOLCHAIN_GCC_AT_LEAST_8".
This issue was introduced in commit
51b60c8acf, when "depends on
BR2_TOOLCHAIN_GCC_AT_LEAST_8" was added to mesa3d, propagated to
intel-mediadriver, but not intel-mediasdk.
Fixes: 51b60c8acf ("package/mesa3d: needs gcc >= 8")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit fa38fea91c)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_PYTHON_MEMRAY selects BR2_PACKAGE_LIBUNWIND but forgot to
propagate "depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9".
Fixes: c2df8bab97 ("package/python-memray: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e36370624d)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_PYTHON_GRPCIO_REFLECTION selects
BR2_PACKAGE_PYTHON_PROTOBUF, but forgot to replicate "depends on
BR2_PACKAGE_HOST_PROTOBUF_ARCH_SUPPORTS".
Fixes: 3217fedcb8 ("package/python-grpcio-reflection: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 74dab03495)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_PYTHON_GOOGLEAPIS_COMMON_PROTOS selects
BR2_PACKAGE_PYTHON_PROTOBUF but did not propagate
BR2_PACKAGE_HOST_PROTOBUF_ARCH_SUPPORTS.
Fixes: d37766a886 ("package/python-googleapis-common-protos: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 548904619c)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Commit 66ddec89e8 ("package/udisks: bump
to version 2.92") mistakenly removed the BR2_USE_MMU dependency of
udisks when dropping "select BR2_PACKAGE_LVM2". Indeed, BR2_USE_MMU is
a dependency of many other packages selected by udisks.
Interestingly, the Config.in comments in the same file still had the
"depends on BR2_USE_MMU" dependencies.
Fixes: 66ddec89e8 ("package/udisks: bump to version 2.92")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 4b8259bad9)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Since bcc was introduced in commit
146498d13c, it lacked a dependency
propagation from clang for BR2_TOOLCHAIN_HAS_GCC_BUG_64735, this
commit fixes this mistake.
Fixes: 146498d13c ("package/bcc: new package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit c305370f36)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS redefines the conditions to
determine if a host go compiler is available for the current host
architecture. Instead, make it explicit that those conditions are the
same by re-using BR2_PACKAGE_HOST_GO_HOST_ARCH_SUPPORTS.
No functional change.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 71d3ffd372)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
In commit
fef9cad1fe ("package/libxmlsec1: bump
version to 1.3.12"), libxmlsec1 was bumped, and alongside some
additional "depends on" were added.
However, these new "depends on" were not propagated to reverse
dependencies of libxmlsec1, i.e. openscap, causing Kconfig warnings:
WARNING: unmet direct dependencies detected for BR2_PACKAGE_LIBXMLSEC1
Depends on [n]: BR2_TOOLCHAIN_GCC_AT_LEAST_7 [=n] && BR2_TOOLCHAIN_HAS_ATOMIC [=n]
Selected by [y]:
- BR2_PACKAGE_OPENSCAP [=y] && BR2_PACKAGE_LIBGPG_ERROR_ARCH_SUPPORTS [=y] && !BR2_STATIC_LIBS [=n] && BR2_TOOLCHAIN_HAS_THREADS_NPTL [=y]
and potentially some build issues, even though we didn't check in the
autobuilders for potential failures.
This commit fixes that by properly propagating the new dependencies.
Cc: Alexis Lothoré <alexis.lothore@bootlin.com>
Cc: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Acked-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 36b2b3f561)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The demo programs, which have always been built and are still enabled by
default, gained a zlib dependency in imlib2 1.12.3: upstream commit
f8a451043871 ("imlib2_load: Add crc32 printout") started using zlib's
crc32() in imlib2_load, and 31006b425e11 ("imlib2_view: Optionally show
crc32 of image data") did the same for imlib2_view. Both hardcoded -lz.
Upstream commit b9555030dace ("autofoo: don't hardcode zlib flags"),
first released in 1.12.4, replaced -lz with $(ZLIB_LIBS) and added an
unconditional PKG_CHECK_MODULES(ZLIB, zlib) to the demo programs branch
of configure, turning the previously silent link-time requirement into a
configure failure:
checking for zlib... no
configure: error: Package requirements (zlib) were not met:
Package 'zlib' not found
As Buildroot went straight from 1.7.3 to 1.12.5 the intermediate state
was never packaged, but the dependency has in fact been missing since the
crc32 support landed.
Fixes: https://autobuild.buildroot.org/results/4e05404c353ef985d74757d0b1ec3eda2cdff523/
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 051e5ab13b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
https://github.com/tukaani-project/xz/releases/tag/v5.8.4
- lzma_alone_decoder(), lzma_lzip_decoder(),
lzma_auto_decoder(), and lzma_microlzma_decoder(): Fix an
invalid memory access after memory allocation has failed and
the application reinitializes the existing decoder to decode
a different file. This bug could at least result in a crash.
This is tracked as GHSA-5qpq-xqfv-j9pg. CVE number is pending.
(Also in v5.2, v5.4, and v5.6.)
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 6f125a6530)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Fixes a sandbox escape through symlink traversal tracked in
CVE-2026-87766, which affects all previous versions.
Using the bwrap binary with the setuid bit set is no longer supported
and user namespaces are now always required, so a kernel config fixup
is applied.
A new build option allows indicating the minimum kernel version that
will be used, which removes code used for backwards compatibility with
kernels older than 5.6.0 when a newer version is specified. Passing
$(LINUX_VERSION_PROBED) seems reasonable here.
This version also changed the license from LGPL-2.0+ to LGPL-2.1+,
hence the updated hash.
Release notes:
https://github.com/containers/bubblewrap/releases/tag/v0.12.0
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
[Julien: fix _LINUX_CONFIG_FIXUPS by adding the missing "_LINUX"]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 4cb6193d2e)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
To indicate that a patch fixes a vulnerability in Buildroot, the convention is:
1. In the patch file, add a tag 'CVE: <cve id>'
2. In <pkg>.mk, and an entry to <PKG>_IGNORE_CVES, and add a comment above
that new entry to reference the patch file(s)
However, as packages get bumped and their patches are added, removed or
rebased; it happens that IGNORE_CVES get outdated. One important issue is
marking a CVE as ignored, while the corresponding patch is not in Buildroot.
To detect such cases, add a new checker to checkpackagelib that finds
occurences of:
# 000x-some-patch.patch
PKG_IGNORE_CVES += CVE-XXXX-YYYY
For each one of them, ensure that the mentioned patch files actually exist
and contain the `CVE: ...` tag.
Assisted-by: Claude:claude-opus-4.8
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit b00ac4e346)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Prior to improving check-package to verify that the comment preceding
a <pkg>_IGNORE_CVES entry mentions an existing patch, and that the
patch itself contains a CVE: tag, we fix all problematic cases that
currently exist in Buildroot:
- In the case of binutils: the CVE was only applicable to binutils
2.43/2.44, and the oldest version now supported is 2.45, so the
patch doesn't exist anymore in Buildroot
- For x11vnc, fix a typo in the patch name
- For gpsd the patches were dropped in [1] as they are included in the
version bump
- Similarly for micropython, the patches were dropped in [2] along with
the version bump
- For util-linux, strip the prefix "package/util-linux/", so that the patch
is relative to the .mk file and can be found by the new check
- Add missing 'CVE:' tag to net-tools patch 0001
[1] 37ef4f862f package/gpsd: bump version to 3.27.2
[2] 28eeca9a98 package/micropython: bump to version 1.28.0
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 636f69ab45)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
https://github.com/PCRE2Project/pcre2/releases/tag/pcre2-10.48
Fixes the following security issues:
(Security fix for specific API usage, GHSA-2p8c-ff85-vh9x)
If pcre2_jit_compile() is called with options for some match modes, and
then pcre2_match() is used to perform a match for a different match
mode, an out-of-bounds read can occur if the match is attempted against
invalid UTF input.
(Security fix for pattern conversion, GHSA-q8g2-wprr-34m9)
If pcre2_convert() is called on untrusted input on platforms with
32-bit size_t, an out-of-bounds heap write can occur.
(Security fix, GHSA-3r4p-g7gg-ppmf) Fixed an out-of-bounds write in DFA
matching when using a heap limit; also fixed possible integer overflows
which could cause under-allocation of the workspace.
(Security fix, GHSA-fmgr-6ggq-9859) Added bounds checks for several
integer overflows while compiling patterns on 32-bit CPUs, which could
cause under-allocation followed by out-of-bounds writes.
(Security fix, GHSA-9qww-pwc4-77qq) Applied lower buffer bound to
prevent two out-of-bounds reads while scanning backwards through
invalid UTF data with PCRE2_MATCH_INVALID_UTF.
(Security fix for specific API usage, #937) Fixed a leak and later
invalid free when calling the fast-path pcre2_jit_match() function with
a match data object previously used with pcre2_match() and
PCRE2_COPY_MATCHED_SUBJECT.
(Low-severity security fix, GHSA-q7rw-r7qq-2hx6) Fixed exposure of two
uninitialised bytes from malloc() via pcre2_serialize_encode().
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 664db5d62c)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
https://github.com/kernelsauce/turbo/releases/tag/v2.1.5https://github.com/kernelsauce/turbo/releases/tag/v2.1.4
Security fixes:
HTTP header injection: header values were only checked for a literal
\r\n, so a lone \r or \n could still split a header. Now rejected on
either character.
Transfer-Encoding requests are now rejected with 501 instead of silently
mishandled, closing a request smuggling avenue.
A real default request body size cap (128 MB) with a 413 response,
previously unbounded.
Secure cookie signature now binds the cookie name, so a value signed for
one cookie can no longer be replayed under a different name.
Verification failures return the default value instead of raising.
Constant-time comparison for the secure cookie HMAC, previously a
timing-leaky ==.
util.secure_random_bytes reads real OS entropy (/dev/urandom,
BCryptGenRandom on Windows) for WebSocket masks and util.rand_str,
previously math.random.
WebSocket: unmasked client frames are rejected per RFC 6455, and
fragmented message reassembly is capped to max_buffer_size to close a
memory exhaustion path.
StaticFileHandler decodes the request path before the traversal check,
closing a bypass.
Fixed a 32-byte-per-malformed-request memory leak in the C header parser
wrapper (found via libFuzzer).
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 15a422cee1)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Upstream started using std::string_view
https://github.com/search?q=repo%3APurpleI2P%2Fi2pd+string_view&type=commits&s=committer-date&o=asc
with commit
a3e0b3710c
first released in version 2.54.0 which was added to buildroot with
commit dea4f02bbb.
Building the package with the gcc6-based defconfig
bootlin-aarch64-glibc-old is broken:
/builds/bkuhls/buildroot/br-test-pkg/bootlin-aarch64-glibc-old/build/i2pd-2.61.0/libi2pd/Base.h:14:23:
fatal error: string_view: No such file or directory
BR2_TOOLCHAIN_HAS_GCC_BUG_64735 can be removed as well now as it depends
on gcc < 7.
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 a6bb4d52c0)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
https://github.com/the-tcpdump-group/libpcap/blob/libpcap-1.10.7/CHANGES
Fixes the following CVEs:
CVE-2026-0799: Access M[] safely in the BPF interpreter.
CVE-2026-31912: Mind the program bounds in pcap_offline_filter().
CVE-2026-31911: Fail opcodes safely in the BPF interpreter.
CVE-2026-6244: Avoid division by zero via pcap_offline_filter().
CVE-2026-6554: Limit "ja L" looping in pcap_offline_filter().
CVE-2026-18313: Fix a memory leak in rpcapd.
CVE-2026-18238: Fix RPCAP_MSG_PACKET validation.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 446c0f85b8)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
igh-ethercat is failing while attempting to apply patches,
with error:
Applying 0002-Linux-6.19.0-support.patch using patch:
patching file devices/generic.c
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file devices/generic.c.rej
The package patch 0002 was added in [1] in branch "master" while it
was in release client cycle. It was cherry-picked in [2] in branch
"next" to apply the bump [3] (which removes the package patches 0001
and 0002). When the branch "next" was merged in "master" in commit [4],
the patch 0002 was kept.
This commit removes this stale patch.
[1] e4cf512c39
[2] 8a5fc970b4
[3] 0a91e760f4
[4] 5f26877955
Fixes:
- https://autobuild.buildroot.org/results/4f509f1f788c1b8dc5a840ffa2e435c5ed7b6eea/
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit d071817969)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
https://github.com/strukturag/libde265/releases/tag/v1.1.2
Security fixes:
(CVE numbers will be added when assigned.)
CVE-2026-XXXXX (GHSA-xp3h-6f5r-8cxp) Heap use-after-free and double free
in multi-threaded (WPP) decoding. A crafted stream whose slice segments
repeat or rewind their slice_segment_address within a picture re-ran
CTB rows that were already marked finished, so the CABAC context handoff
between rows was no longer ordered and the shared context table was
released twice. Slice segments that do not follow the previous one in
tile-scan order are now rejected with the new warning
DE265_WARNING_SLICE_SEGMENT_ADDRESS_NOT_INCREASING, and the WPP row
progress is reset for each slice segment. (medium)
CVE-2026-XXXXX (GHSA-mm7m-v26f-wf8x) Heap use-after-free after
de265_reset(): the pointer to the previous slice header was left
dangling when the DPB was cleared, and a dependent slice pushed after
the reset copied from freed memory. (medium)
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit e55cb31085)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
https://github.com/strukturag/libheif/releases/tag/v1.23.3
Fixes the following CVEs:
(CVE numbers will be added when assigned.)
CVE-2026-XXXXX (GHSA-x8r2-mggj-j6wr) Heap buffer overflow (write) in the
uncompressed (unci) mixed-interleave decoder when the two chroma
components declare different bit depths. Both the written bytes and the
overflow length are controlled by the file. (critical)
CVE-2026-XXXXX (GHSA-8fmq-r4pf-7m57) Permanent decoder deadlock through
a reference cycle between an image and its alpha auxiliary image. The
alpha edge was not covered by the cycle guard and re-entered a held
mutex. (high)
CVE-2026-XXXXX (GHSA-w7mc-p8jc-p853) Heap out-of-bounds read in the
YCbCr 4:2:0 to 16-bit interleaved RGB conversion when the chroma
planes have a lower bit depth than luma. Heap memory could end up in
the decoded image. YCbCr conversions with mismatched luma and chroma
bit depths are now rejected. (high)
CVE-2026-XXXXX (GHSA-4jqm-2x34-6f6r) Heap buffer overflow in the SVT-AV1
encoder plugin when encoding a high-bit-depth alpha channel, and a
double free on its send-picture error path. (high)
CVE-2026-84451 (GHSA-hh47-fhqr-cj2r) Incomplete fix for
GHSA-73p7-m7gg-w2jv: the tile range check of the unci decoder (without
icef) could still overflow, allowing an out-of-bounds read. (medium)
CVE-2026-XXXXX (GHSA-4h82-g446-83fm) Heap out-of-bounds read when
converting odd-height 4:2:0 frames of an uncompressed (uncv) image
sequence to RGB. (medium)
CVE-2026-XXXXX (GHSA-9rj8-5mp5-26c9) Out-of-bounds read in the RGB to
YCbCr identity-matrix color conversion when the R, G, and B planes
have different bit depths. (medium)
CVE-2026-84450 (GHSA-gh5q-69gg-c964) A clap property combined with an
oversized ispe reached an assert() in the Fraction arithmetic and
aborted the process (incomplete fix for GHSA-jc8f-p23p-5hjg). An error
is returned instead. (medium)
(GHSA-mw6f-29j3-76f4) Several smaller findings:
heif_image_handle_get_depth_image_handle() and
heif_image_handle_get_depth_image_representation_info() dereferenced a
null pointer on files without a depth image; the TIFF input decoder of
the example tools had an unbounded EXIF tag allocation and a division
by zero on zero YCbCr subsampling; assert()s in the PNG input decoder
are now error returns; integer overflow in the Go binding's
ImageAccess.GetPlane(); heif-view now verifies the decoded frame size
before display. (medium)
(GHSA-8857-r8x5-7499) Undefined behavior (negative shift) in the HDR
bit-depth up-conversion for target bit depths above 16. Such
conversions are now rejected. (low)
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit d148168e20)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Buildroot commit 9a43bf6593 bumped the gcc
dependency from 9 to 10 but forgot to propagate this change to the
libcamera-apps package.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 64ed9e6c43)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Buildroot 262a7f6d2f added the package but
forgot to provide the hash for LICENSE.GPL3-EXCEPT, instead a hash for
a non-existing file was added to qt5knx.hash.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit d2b7199dea)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Regenerate the Bootlin toolchain Kconfig and test configurations using
support/scripts/gen-bootlin-toolchains.
This adds BR2_USE_MMU to the affected uClibc entries and to the
architecture support conditions, and updates the generated tests.
The glibc and musl changes only reorder their existing BR2_USE_MMU
dependencies.
Signed-off-by: Fengwei Tan <tfx2001@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 9c6eed9ec0)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
The Bootlin uClibc toolchains for m68k-68xxx, riscv32-ilp32d, and
xtensa-lx60 require an MMU. However, their generated Kconfig entries
lack a BR2_USE_MMU dependency, allowing them to be selected for noMMU
configurations. External toolchain validation then fails with:
MMU support available in C library, please enable BR2_USE_MMU
Add the missing BR2_USE_MMU dependencies for these architectures to
prevent them from being selected for noMMU targets.
Signed-off-by: Fengwei Tan <tfx2001@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 3469c6793c)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Regenerate the Bootlin toolchain Kconfig file with
support/scripts/gen-bootlin-toolchains to remove duplicate
BR2_TOOLCHAIN_HAS_THREADS selections.
Commit 184d47a7ad ("support/scripts/gen-bootlin-toolchains: add new
script to support Bootlin toolchains") initially introduced this issue.
Although commit a33e1af4a0 ("support/scripts/gen-bootlin-toolchains:
avoid selecting _HAS_THREADS multiple times") fixed the generator script,
the Config.in.options file was not regenerated accordingly.
This is a non-functional cleanup, as repeated Kconfig select statements
are harmless.
Signed-off-by: Fengwei Tan <tfx2001@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 9556895e78)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
dtui depends on tui-textarea which unconditionally imports AtomicU64 in
src/widget.rs to pack a viewport rectangle into a single atomic word:
use std::sync::atomic::{AtomicU64, Ordering};
pub struct Viewport(AtomicU64);
As there is no cfg(target_has_atomic) guard in tui-textarea, its
build fails on any target for which rustc does not provide 64-bit
atomics with:
Compiling tui-textarea v0.7.0
error[E0432]: unresolved import `std::sync::atomic::AtomicU64`
--> .../dtui-3.0.0/VENDOR/tui-textarea/src/widget.rs:10:25
|
10 | use std::sync::atomic::{AtomicU64, Ordering};
| ^^^^^^^^^ no `AtomicU64` in `sync::atomic`
|
help: a similar name exists in the module
|
10 - use std::sync::atomic::{AtomicU64, Ordering};
10 + use std::sync::atomic::{AtomicU32, Ordering};
This has been reported to tui-textarea upstream, but unfortunately the
project seems to be unmaintained (issue linked below). A sane workaround
is to disable the package on targets which lack 64-bit atomic support,
which is exactly what BR2_PACKAGE_HOST_RUSTC_TARGET_HAS_ATOMIC_U64
describes: it is n for armv5te-unknown-linux-{gnu,musl}eabi and
powerpc-unknown-linux-gnu, the only rust targets Buildroot can generate
which lack 64-bit atomics, and y everywhere else.
The same problem was hit by package/dust and worked around in commit
3abc3b97ba ("package/dust: bump to version 1.1.2") by bumping to a
version in which upstream had added the missing guard. That is not an
option here as tui-textarea 0.7.0 is the latest release.
Note that a runtime test for dtui cannot use the default
infra.basetest.BASIC_TOOLCHAIN_CONFIG, since that builds with
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE, where dtui is now
disabled; such a test would need an armv7 or aarch64 toolchain instead.
Build tested with utils/test-pkg against:
- BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE
- BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_MUSL_STABLE
- BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_POWERPC_E500MC_GLIBC_STABLE
all three fail with the above error before this change and are skipped
after it, while armv7 (glibc and musl), aarch64, powerpc64le and x86-64
still select and build the package.
Link: https://github.com/rhysd/tui-textarea/issues/66
Fixes: https://autobuild.buildroot.org/results/188f6442371500731453f75983590c922eab6d57
Fixes: https://autobuild.buildroot.org/results/e254db2654f18f1d2110eb8b1a32b43ad0f2a3d6
Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 99529edaef)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Rust does not provide 64-bit atomics on every target Buildroot can
generate. rustc sets max_atomic_width = 32 for three of the 25 targets
listed in RUST_TARGETS in utils/update-rust, so
core::sync::atomic::AtomicU64 and AtomicI64 simply do not exist there:
$ rustc --print cfg --target <target> | grep target_has_atomic
armv5te-unknown-linux-gnueabi "16" "32" "8" "ptr"
armv5te-unknown-linux-musleabi "16" "32" "8" "ptr"
powerpc-unknown-linux-gnu "16" "32" "8" "ptr"
Every other supported target, including armv6, armv7, aarch64, all the
x86 variants, riscv64, s390x, sparc64 and both 64-bit powerpcs, has
them, e.g.:
arm-unknown-linux-gnueabi "16" "32" "64" "8" "ptr"
armv7-unknown-linux-gnueabihf "16" "32" "64" "8" "ptr"
A crate that uses 64-bit atomics without a cfg(target_has_atomic = "64")
guard therefore fails to build on those three targets with:
error[E0432]: unresolved import `std::sync::atomic::AtomicU64`
|
| atomic::{AtomicU64, AtomicU8, AtomicUsize, Ordering},
| ^^^^^^^^^ no `AtomicU64` in `sync::atomic`
This has been hit at least twice already: by package/dust, worked around
in commit 3abc3b97ba ("package/dust: bump to version 1.1.2") by moving
to a release in which upstream had added the guard and by package/dtui,
which has no such release available and had to open-code the affected
architectures instead.
It is likely to keep recurring: infra.basetest.BASIC_TOOLCHAIN_CONFIG
builds with BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV5_EABI_GLIBC_STABLE, so
every runtime test that does not override the toolchain compiles for
armv5te, one of the three affected targets. That is exactly how the two
failures above were found.
Add a hidden symbol so packages can express this constraint once, rather
than each open-coding BR2_ARM_CPU_ARMV5 and BR2_powerpc and needing to
update whenever rust gains or changes a target.
Note that armv5te and 32-bit powerpc are only supported by rust for
glibc and musl, so the uclibc variants of those architectures are
already excluded by BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS.
Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 698535473f)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
DEJAVU_LICENSE is primarily BitstreamVera. The license file also
specifies that DejaVu-specific changes and certain math extensions are
in the Public Domain. This matches the licensing logic used by
OpenEmbedded/Yocto.
Signed-off-by: Martin Bachmann <martin.bachmann@designwerk.com>
[Fiona: wrap lines in commit message]
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
(cherry picked from commit df61b7e9bb)
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
From 32fe99fa403d2f51931615745a64f8aede1ca46f Mon Sep 17 00:00:00 2001
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Date: Sat, 8 Jan 2022 13:38:17 +0100
Subject: [PATCH] src/est/est_locl.h: add missing extern on
e_ctx_ssl_exdata_index
Without this extern, the variable gets re-declared in each compilation
unit including est_locl.h, causing gcc >= 10 to complain with:
/home/thomas/projets/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/10.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: .libs/est_client.o:(.data+0x0): multiple definition of `e_ctx_ssl_exdata_index'; .libs/est.o:(.bss+0x8): first defined here
/home/thomas/projets/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/10.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: .libs/est_server.o:(.bss+0xc): multiple definition of `e_ctx_ssl_exdata_index'; .libs/est.o:(.bss+0x8): first defined here
/home/thomas/projets/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/10.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: .libs/est_server_http.o:(.bss+0x3b8): multiple definition of `e_ctx_ssl_exdata_index'; .libs/est.o:(.bss+0x8): first defined here
/home/thomas/projets/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/10.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: .libs/est_proxy.o:(.bss+0x0): multiple definition of `e_ctx_ssl_exdata_index'; .libs/est.o:(.bss+0x8): first defined here
/home/thomas/projets/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/10.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: .libs/est_client_http.o:(.bss+0x0): multiple definition of `e_ctx_ssl_exdata_index'; .libs/est.o:(.bss+0x8): first defined here
/home/thomas/projets/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/10.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: .libs/est_ossl_util.o:(.bss+0x0): multiple definition of `e_ctx_ssl_exdata_index'; .libs/est.o:(.bss+0x8): first defined here
/home/thomas/projets/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/10.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: .libs/est_client_proxy.o:(.bss+0x0): multiple definition of `e_ctx_ssl_exdata_index'; .libs/est.o:(.bss+0x8): first defined here
/home/thomas/projets/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/10.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: .libs/est_enhcd_cert_auth.o:(.bss+0x0): multiple definition of `e_ctx_ssl_exdata_index'; .libs/est.o:(.bss+0x8): first defined here
/home/thomas/projets/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/10.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: .libs/est_server_coap.o:(.bss+0x0): multiple definition of `e_ctx_ssl_exdata_index'; .libs/est.o:(.bss+0x8): first defined here
default BR2_DEFAULT_KERNEL_VERSION if BR2_KERNEL_HEADERS_VERSION
default "custom" if BR2_KERNEL_HEADERS_CUSTOM_TARBALL
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
