The following dependency:
depends on !BR2_TOOLCHAIN_USES_UCLIBC || BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_1
was added by commit d63e207eb8, which
bumped python3 from 3.12.9 to 3.13.2.
The commit message doesn't state it, but this dependency was introduced
because uClibc without time64 support (i.e. with kernel headers < 5.1)
causes a runtime assertion in Python [1]:
OverflowError: timestamp too large to convert to C PyTime_t
The problem is that this dependency has not been propagated to reverse
dependencies, causing this kind of kconfig warnings:
WARNING: unmet direct dependencies detected for BR2_PACKAGE_PYTHON3
Depends on [n]: BR2_USE_WCHAR [=y] && BR2_USE_MMU [=y] && BR2_TOOLCHAIN_HAS_THREADS [=y] && !BR2_STATIC_LIBS [=n] && (!BR2_TOOLCHAIN_USES_UCLIBC [=y] || BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_1 [=n])
Selected by [y]:
- BR2_PACKAGE_AVOCADO [=y] && BR2_USE_WCHAR [=y] && BR2_USE_MMU [=y] && BR2_TOOLCHAIN_HAS_THREADS [=y] && !BR2_STATIC_LIBS [=n]
- BR2_PACKAGE_LIBSIGROKDECODE [=y] && BR2_USE_WCHAR [=y] && BR2_TOOLCHAIN_HAS_THREADS [=y] && BR2_USE_MMU [=y] && !BR2_STATIC_LIBS [=n]
- BR2_PACKAGE_OPKG_UTILS [=y] && BR2_PACKAGE_BUSYBOX [=y] && BR2_USE_MMU [=y] && BR2_USE_WCHAR [=y] && BR2_TOOLCHAIN_HAS_THREADS [=y] && !BR2_STATIC_LIBS [=n]
However, propagating this dependency to all reverse dependencies of
python3 would be pretty annoying, especially as the dependency is kind
of "clunky". A configuration with uClibc and kernel headers < 5.1 is
such a corner case that it does not merit such complexity.
A later commit will check for this corner case at build time (while
allowing it in the .config). For now, already drop the dependency in
Config.in.
Cc: Vincent Fazio <vfazio@xes-inc.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
[1] https://gitlab.com/buildroot.org/buildroot/-/issues/95#note_2348479811
Since glibc 2.28, <sys/sysmacros.h> is no longer implicitly included
by <sys/types.h>, which means major() is only defined if you include
<sys/sysmacros.h>.
This wasn't really visible for a while in loadable plugins built by
lirc-tools as they could happily be built with undefined
symbols... except they would fail to load at runtime.
But then GCC 14.x brought more strict checking of having the function
prototype around, which now detects this issue at build time.
So the actual issue has been around since we switched to glibc 2.28,
but it only started failing to build since gcc 14.x. The first failure
is on August 2024, so this patch should be backported to our stable
branches.
The fix is backport from an upstream commit, post 0.10.2.
Fixes:
https://autobuild.buildroot.net/results/2f64accd430d9467add3f1195f3f59eff8e99a4d/
Minimal reproducer:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_GLIBC_STABLE=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_LIRC_TOOLS=y
# BR2_TARGET_ROOTFS_TAR is not set
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, the manual doesn't mention the checkpackageignore file at
all, leaving the user under the assumption that running "make
check-package" and running utils/check-package directly on the package
they have touched would be equivalent, when the former evaluates the
checkpackageignore file while the latter does not. This could cause them
to forget to remove stale entries from that file.
Point out this difference in behavior.
Signed-off-by: Florian Larysch <fl@n621.de>
[Arnout: add that stale lines should be removed from
.checkpackageignore]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Since the bump of libftdi1 to version v1.5-48-g22b4667a8 in commit
d8173e084e, the libftdi1.pc file is
installed in $(STAGING_DIR)/pkgconfig/libftdi1.pc instead of
$(STAGING_DIR)/lib/pkgconfig/libftdi1.pc, making it "invisible" to
pkg-config. This is turn causes flashrom to not find libftdi1 and
failing to build when libftdi1 is needed.
This issue is cause by CMAKE_INSTALL_LIBDIR being empty in libftdi1's
CMakeLists.txt, which in turn is due to include(GNUInstallDirs) being
missing. This has been fixed upstream a few commits later, so rather
than backporting a patch, let's just update to the commit containing
the fix, 5e67403c4fb5536a2effe2e91181dd73a2cff91b. The list of changes
upstream is:
5e67403c4fb5536a2effe2e91181dd73a2cff91b cmake: fix building static lib on windows/msvc
2e714eec137f86ca1950457d8226d8cb9b71c495 msvc: quiet uninteresting warnings
d96dbea887373f26755e9873b4ab020f922b7c3b fix unit var warning if ftdi_read_eeprom_location returned error, data would not be initialized
d31e3d5697eacbe87cd310b5bce615f3d8426cc0 cmake: fix elseif statement
c2b7c25e1272222c1719daea5761093fbc9c3010 msvc: fix shadowed variable warning
c4962c38a1ab470fbdc835c231567bd582eb5a5a msvc: fix warnings by using all enum values in case statements
2a992306c0acf938b29fa0cd5fbc160e24424209 Add SHAREDLIBS option
18499a2fa496c20e5e35590bb89eb701fa9fdfea Ignore VSCode temp folder
7676fb59ecd9fac9e5ea39439905c923ee7ee8c9 python/CMakeLists.txt: rework policy CMP0078
cfaec73e0a5ad9d05d62f1f5c393ab1c59ba771b C++ wrapper: get rid of the Boost dependency
12a8de0daba0816227c7010fc1b84d0abf70a500 .editorconfig: fix insert_final_newline option
3d7293651483130af9e8c5fe685d28b226baa99b Ignore clangd specific files
72e0e1e40126a2a9498fb249ca26a727bd670139 examples/async.c: remove unused includes
bfcdea286df81660b980a3bc91902b5970ff6347 examples/async.c: fix sometimes-uninitialized warning
(Yes the commit containing the fix is titled "cmake: fix building
static lib on windows/msvc", but because it adds
include(GNUInstallDirs), it also fixes our problem).
Fixes:
https://autobuild.buildroot.net/results/3600a9b7f323b4610ac67feb7171c0e10b6383d7/
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
This defconfig no longer builds:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11012272989
It has been broken for at least 2 months, and it has no maintainer in
the DEVELOPERS file. We're adding Bartosz Bilas who has been the last
person doing updates to this defconfig.
Unless some fixes are provided, this defconfig will be dropped from
Buildroot.
Cc: Bartosz Bilas <b.bilas@grinn-global.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
The old one lasted for 10 years, lately spam
levels reached a rather uncomfortable level ...
Signed-off-by: Andreas Ziegler <br015@umbiko.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Buildroot commit [1] "package/python-pyroute2: bump to version 0.9.4"
added the python3 ssl runtime dependency while updating the package
in the "next" branch. It incorrectly suggested the dependency was
introduced in version 0.9.4.
This dependency was in fact introduced in upstream commit [2],
first time included in pyroute2 0.8.1, which is the current version
in the Buildroot release stabilization branch. It is worth mentioning
that this package was updated to that version in Buildroot commit [3].
Running the command on target:
python3 -c 'import pyroute2'
Fails at runtime with error:
ModuleNotFoundError: No module named '_ssl'
This commit fixes the issue by adding this missing dependency,
the same was it was done in commit [1].
[1] 786557d859
[2] e87c14581b
[3] 816641bbe1
Signed-off-by: Yacin Belmihoub-Martel <yacin.belmihoub-martel@silabs.com>
[Julien:
- reword commit log
- add the "runtime" comment
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
This patch removes the xilinx_v2024.2 hashes since all xilinx defconfigs have
been bumped to xilinx_v2025.1.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Fixes the following CVEs:
- CVE-2024-41957
- CVE-2024-41965
- CVE-2024-45306
- CVE-2024-47814
- CVE-2025-1215
- CVE-2025-22134
- CVE-2025-24014
- CVE-2025-26603
- CVE-2025-29768
- CVE-2025-53905
- CVE-2025-53906
README.txt got updated three times since the last bump:
- [0] updated some wording regarding who the developers are.
- [1] updated the link to the release archives
- [2] updated the goals of the project
netrw (the builtin file explorer of vim) changed maintainer and was
subsequently restructured [3]. Therefore we need to run installpack,
otherwise we run into this on startup (reported by Julien, thanks!):
Error detected while processing
/usr/share/vim/vim91/plugin/netrwPlugin.vim:
line 7:
E919: Directory not found in 'packpath': "pack/*/opt/netrw"
Press ENTER or type command to continue
[0]: b75825f749
[1]: 4225f28855
[2]: 2bfd1ee161
[3]: 9cfdabb074
Signed-off-by: Daniel Lang <dalang@gmx.at>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since Buildroot commit [1] "update to Bootlin toolchains 2025.08-1",
the TestXvisor fails when building xvisor with gcc 15.1.0.
Since xvisor is now fixed, opensbi 1.5 fail to build with gcc-15 for
the same reasons.
opensbi 1.6 include a fix for C23 enabled compilers [2]
[1] 947dbc92a2
[2] d539d64a23
Cc: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since Buildroot commit [1] "update to Bootlin toolchains 2025.08-1",
the TestXvisor fails when building xvisor with gcc 15.1.0.
GCC 15 changed the default C standard version to C23 [2], resulting in
errors from the xvisor definitions of bool from core/include/vmm_types.h,
which is a reserved keyword under C23.
Since CFLAGS are hardcoded in the main Makefile, add '-std=gnu11' to
'cflags' to resolve the error.
[1] 947dbc92a2
[2] https://gcc.gnu.org/gcc-15/porting_to.html
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11042295047
Cc: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
On both Buildroot 2025.02.x and master branch, php-lua build fails on
the following error:
lua.c:862:44: error: assignment to 'zend_object_write_property_t' {aka
'struct _zval_struct * (*)(struct _zend_object *, struct _zend_string *,
struct _zval_struct *, void **)'} from incompatible pointer type 'void
(*)(zval *, zval *, zval *, void **)' {aka 'void (*)(struct _zval_struct
*, struct _zval_struct *, struct _zval_struct *, void **)'}
[-Wincompatible-pointer-types]
862 | lua_object_handlers.write_property =
php_lua_write_property;
| ^
lua.c:863:44: error: assignment to 'zend_object_read_property_t' {aka
'struct _zval_struct * (*)(struct _zend_object *, struct _zend_string *,
int, void **, struct _zval_struct *)'} from incompatible pointer type
'zval * (*)(zval *, zval *, int, void **, zval *)' {aka 'struct
_zval_struct * (*)(struct _zval_struct *, struct _zval_struct *, int,
void **, struct _zval_struct *)'} [-Wincompatible-pointer-types]
863 | lua_object_handlers.read_property =
php_lua_read_property;
| ^
make[2]: *** [Makefile:214: lua.lo] Error 1
The error can be reproduced with the following minimal defconfig:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_NEON=y
BR2_ARM_ENABLE_VFP=y
BR2_ARM_FPU_NEON=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_LUA=y
BR2_PACKAGE_PHP=y
BR2_PACKAGE_PHP_LUA=y
This build failure is the result of two events/conditions:
- the update to PHP8 has changed the prototype for
zend_object_read_property_t (see [1]). But at this time, php-lua just
generated a new warning (-Wincompatible-pointer-types)
- using bootlin bleeding-edge toolchain brings in GCC14, which now turns
this warning into a systematic error (see [2])
This issue is still present on the upstream repository, but it has been
fixed on one of its forks. Bring the relevant patch from the fork to
allow building php-lua.
[1] https://github.com/php/php-src/commit/91ef4124e56
[2] https://gcc.gnu.org/gcc-14/porting_to.html#incompatible-pointer-types
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
[Romain: update Upstream link]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Fix the following vulnerability:
- CVE-2025-46728
cpp-httplib is a C++ header-only HTTP/HTTPS server and client library.
Prior to version 0.20.1, the library fails to enforce configured size
limits on incoming request bodies when `Transfer-Encoding: chunked` is
used or when no `Content-Length` header is provided. A remote attacker
can send a chunked request without the terminating zero-length chunk,
causing uncontrolled memory allocation on the server. This leads to
potential exhaustion of system memory and results in a server crash or
unresponsiveness. Version 0.20.1 fixes the issue by enforcing limits
during parsing. If the limit is exceeded at any point during reading,
the connection is terminated immediately. A short-term workaround
through a Reverse Proxy is available. If updating the library
immediately is not feasible, deploy a reverse proxy (e.g., Nginx,
HAProxy) in front of the `cpp-httplib` application. Configure the
proxy to enforce maximum request body size limits, thereby stopping
excessively large requests before they reach the vulnerable library
code.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2025-46728
- 7b752106ac
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
(cherry picked from commit aea7c89396)
Signed-off-by: Julien Olivain <ju.o@free.fr>
This reverts commit 559bb33ae7, which
was disabling BR2_BACKUP_SITE in our tests with the following
reasoning:
support/testing: do not use s.b.o
Currently, the runtime tests will use the sources.buildroot.org backup
mirror, which is the default setup.
However, in some cases we do not want to use the backup site, because we
want to ensure that the download actually works.
This is the case for vendored packages, like cargo or golang packages,
for whbich we want to check that gthe download still works when we
update the rust or go versions, or when our download helpers change.
So, disable the use of the backup site in all runtime tests, and drop
the no-longer needed special cases.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
However, not using the backup site is causing a LOT of random failures
in Gitlab CI, making the results barely usable. Since it's more
important to get real failures than random ones due to download
issues, let's re-enable BR2_BACKUP_SITE in our testing infrastructure.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
The 6.15.x series is now EOL upstream, so drop the linux-headers
option and add legacy handling for it.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since upstream commit 312efb2acba7dba80b6652ccf98339dcbbd47695, the
JPEG loading code is using jpeg_read_icc_profile(), which is only
available when the jpeg-turbo implementation is used, not the classic
libjpeg. When classic jpeg is used, the build fails with:
../shared/image-loader.c:163:14: error: implicit declaration of function 'jpeg_read_icc_profile' [-Wimplicit-function-declaration]
163 | if (!jpeg_read_icc_profile(cinfo, &profdata, &proflen)) {
This commit first appeared in development version 13.0.91 and stable
version 14.0.0, which means the problem exists in Buildroot since
commit 430b80cfc1, when weston was
bumped from 13.0.3 to 14.0.0.
So let's enable the JPEG logic only when jpeg-turbo is used.
Fixes:
https://autobuild.buildroot.org/results/353e39902616bdbce40ac667e98cbaf51079f69e/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since upstream commit 66e1614122c22d455cc3a28db08b3afac2b7be29, which
first appeared in version 1.11.0, back in 2016, jpeg is no longer a
mandatory dependency. And in fact, Buildroot no longer has it
unconditionally in WESTON_DEPENDENCIES since commit
f67a6e9b7a, but BR2_PACKAGE_WESTON is
still selecting in.
A build without libjpeg works just fine, so let's drop this select.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
When BR2_BINUTILS_GPROFNG=y, the build currently fails with GCC 15.x,
of course on architectures for which gprofng is actually
available. This issue only exists in binutils 2.42 and 2.43.1, as
binutils 2.44 has the necessary fixes.
Therefore, this commit backports the relevant commits from binutils
2.44 to 2.43.1 and 2.42.
Fixes:
https://autobuild.buildroot.net/results/7cf52019f87625c73ef3c4ca0b6270e20a4ab768/ (binutils 2.42)
https://autobuild.buildroot.net/results/478e24af1a03dea5ec64b77ca611b4f7225c9d39/ (binutils 2.43.1)
The following defconfig, built under a Fedora 42 Docker container
allows to reproduce the issue:
BR2_x86_nehalem=y
BR2_BINUTILS_VERSION_2_42_X=y
BR2_BINUTILS_GPROFNG=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
# BR2_TARGET_ROOTFS_TAR is not set
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
The binutils-gdb code base in Git does have a copy of readline that is
used by gdb.
The release tarballs of binutils do NOT contain readline as it's not
needed for binutils itself (only gdb).
However, when we build the ARC binutils, taken from Git, the readline/
folder is present, and therefore readline is built even if it is not
actually needed.
This causes build failures as the copy of readline in ARC binutils
2024.12 (based on binutils 2.43) does not build with GCC 15.x.
To work around this problem, we use a suggestion from Waldemar
Brodkorb: pass --with-system-readline. Indeed, this disables the build
of readline... but it does not actually check that we have a system
readline, since we're not building gdb.
Fixes:
https://autobuild.buildroot.net/results/976243181f7000fe2790b3450bdae51e8c12769e/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Some packages such as SDL2 do this:
WAYLAND_SCANNER=`$PKG_CONFIG --variable=wayland_scanner wayland-scanner`
to find the path to the wayland-scanner tool.
Of course, since SDL2 is compiled for the target, it does that using
the pkg-config configured for cross-compilation, which looks at
$(STAGING_DIR)/usr/lib/pkgconfig/wayland-scanner.pc.
Since it looks at the variable wayland_scanner, which doesn't get
prefixed by PKG_CONFIG_SYSROOT_DIR, the SDL2 configure script is told
that wayland-scanner is in /usr/bin/wayland-scanner causing this kind
of build failure:
/bin/bash: line 1: /usr/bin/wayland-scanner: No such file or directory
/bin/bash: line 1: /usr/bin/wayland-scanner: No such file or directory
when building SDL2.
The target wayland package depends on host-wayland, which most notably
is responsible for installing wayland-scanner in $(HOST_DIR)/bin.
So in order to fix the SDL2 build issue but in a global way (possibly
helping other packages), what this patch does is tweak the
wayland-scanner.pc installed by the target wayland so that its
wayland_scanner variable points to the host wayland-scanner
executable. We find this a better solution than passing a
WAYLAND_SCANNER variable to each and every package that needs
wayland-scanner.
The issue is not visible in the autobuilders, but can be reproduced
using the following defconfig:
BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_VFP=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_SDL2=y
BR2_PACKAGE_SDL2_WAYLAND=y
BR2_PACKAGE_SDL2_OPENGLES=y
BR2_PACKAGE_RPI_USERLAND=y
BR2_PACKAGE_WAYLAND=y
# BR2_TARGET_ROOTFS_TAR is not set
Note: Make sure that wayland-scanner is not be installed on the build
host to reproduce the issue.
The issue probably exists since WAYLAND_SCANNER was retrieved using
pkg-config in SDL2's configure.ac script, in upstream commit
19d3500ae19636f3f410e270f12e0bc5e83410d4, which got first introduced
in release-2.0.5 of SDL2.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Romain: add a comment about wayland-scanner to reproduce the issue]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
