Blake3 unconditionally enables C++ support, which unconditionally
requires C++20 when built with cmake >= 3.12, even when this is not
required.
Fixing this does not look trivial, and rather than botching the build,
just require C++20, available from gcc 8.x onward.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Use of threading requires a C++20 compiler, and the oneTBB
implementation. oneTBB is missing from Buildroot, but a system
one may be used if found.
Even if the default for threading is disabled, explicitly state so,
in case the default changes in the future.
Also disable examples, we don't and won't need them.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Ensure that the SHA_CRYPT option is enabled when the system configuration is
set to SHA256/512, as otherwise passwd complains when a password is changed:
passwd
...
Invalid ENCRYPT_METHOD value: 'SHA512'.
Defaulting to DES.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
As described in https://gitlab.com/buildroot.org/buildroot/-/issues/160, the
github mirror is getting shut down - So move to the sourceware.org git repo.
The github mirror was originally used because of performance and reliability
issues with sourceware, but that seems be resolved now after server/RAM
upgrades - E.G. from the sourceware news:
April 22, 2024
server2.sourceware.org now has 512GB RAM, thanks Red Hat.
https://sourceware.org/
So change back to fetch glibc (and localedef) from sourceware.org over git.
Notice: The git archiving leads to slightly different paths and permissions
in the tarball, but the file content is identical:
mkdir a && tar -C a -x --strip-components=1 -f \
path/to/glibc-2.42-51-gcbf39c26b25801e9bc88499b4fd361ac172d4125.tar.gz
mkdir b && tar -C b -x --strip-components=1 -f \
path/to/glibc-2.42-51-gcbf39c26b25801e9bc88499b4fd361ac172d4125-git4.tar.gz
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Julien:
- add missing SoB line
- fix command lines in commit log
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Unfortunately, if all optee-related packages are not updated at the same
time, optee-test will not build. This commit bumps all the optee
components at once.
The version bump is needed since optee-examples and optee-test can no
longer compile (compatibility with CMake < 3.5 has been removed from
CMake).
For release details, see:
https://github.com/OP-TEE/optee_os/blob/4.9.0/CHANGELOG.md#op-tee---version-490-2026-01-16
Signed-off-by: Jakob Kastelic <jkastelic@thinksrs.com>
[Julien: add link to release details]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since commit 0e3ddc9dc8 "{linux,
linux-headers}: split hash file in before and from 6.17" there are two
hash file variants, and symlinks for the individual versions. These
were not updated in 48186093fd "bump
5.{10, 15}.x / 6.{1, 6, 12, 18}.x series".
Fixes: 48186093fd
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Swig has a compiled in absolute path to its data files, which can be
overridden using the SWIG_LIB environment variable:
https://github.com/swig/swig/blob/v4.1.1/Source/Modules/main.cxx#L931-L945
This unfortunately means that host-swig misbehaves when used in the SDK, as
this points to the ${HOST_DIR}/bin of the build, which may not be available
when the SDK is used.
The issue was reported upstream but rejected in
https://github.com/swig/swig/issues/253, so instead add a wrapper script
which calculates a sensible SWIG_LIB relative to the wrapper location unless
SWIG_LIB is set, similar to how we do it for E.G. gcc or pkgconf.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: add quotes to make shellcheck happy]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit [1] introduced a patch to fix CVE-2025-62291. Since [2] the
security patches neeed to reference the vulnerability with the `CVE: `
trailer in the patch header.
[1] b009935e27 package/strongswan: add patch to fix CVE-2025-62291
[2] 1167d0ff3d docs/manual: mention CVE trailer
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
On Buildroot 2025.05.3, Meson's custom LLVM parser uses llvm-config
with a default search path of /usr/bin, causing it to detect the host
system's llvm-config (version 18.1.3) instead of the buildroot-compiled
one. This forces all LLVM-related packages to match version 18.1.3, but
since the host system lacks llvmspirvlib, the build fails. This patch
forces Meson to use the buildroot-compiled llvm-config.
On the master branch, the meson is somehow able to find the right
llvm-config, so reproduction only seems to be possible if the host
machine ships with a newer version as the one buildroot is using.
llvm-config found: YES
([...]/output/host/bin/llvm-config)
21.1.8
Run-time dependency LLVM (modules: bitwriter, core, coverage, engine,
executionengine, instcombine, irreader, libdriver, linker, lto,
mcdisassembler, mcjit, native, option, scalaropts, target,
transformutils, all-targets, coroutines, frontenddriver, frontendhlsl,
lto, windowsdriver) found: YES 21.1.8
Note that LLVM_CONFIG is a CMake option, not a Meson one. This is because
Meson has custom dependency resolution logic for LLVM (see
https://mesonbuild.com/Dependencies.html#llvm). The EXTRA_BINARIES mechanism
cannot be used here, as it only applies to cross-compilation scenarios, which
does not apply to host-mesa3d builds.
Reproduction (On BR2 tag: 2025.05.3):
BR2_x86_64=y
BR2_x86_atom=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_X86_64_GLIBC_STABLE=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.1.24"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/pc/linux.config"
BR2_LINUX_KERNEL_INSTALL_TARGET=y
BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_LLVM=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_I915=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_IRIS=y
BR2_PACKAGE_MESA3D_OPENGL_EGL=y
BR2_PACKAGE_MESA3D_OPENGL_ES=y
Fixes:
llvm-config found: YES (/usr/bin/llvm-config-18) 18.1.3
Run-time dependency LLVM (modules: bitwriter, core, coverage, engine, executionengine, instcombine, irreader, libdriver, linker, lto, mcdisassembler, mcjit, native, option, scalaropts, target, transformutils, all-targets, coroutines, frontenddriver, frontendhlsl, lto, windowsdriver) found: YES 18.1.3
Dependency LLVMSPIRVLib found: NO. Found 15.0.0.0 but need: '>= 18.1' ; matched: '>= 15.0.0.0', '< 18.2'
Run-time dependency llvmspirvlib found: NO (tried cmake)
output/build/host-mesa3d-25.0.6/meson.build:1882:21: ERROR: Dependency lookup for LLVMSPIRVLib with method 'pkgconfig' failed: Invalid version, need 'LLVMSPIRVLib' ['>= 18.1'] found '15.0.0.0'.
Signed-off-by: Thomas Devoogdt <thomas.devoogdt@barco.com>
[Romain:
- Update the commit title
- Update commit log about this issue on master branch
https://lore.kernel.org/buildroot/CACXRmJh1-5Cy92kF9TM5nDs_uB90WAe5iOGmNNL2E-cMhJE7GA@mail.gmail.com/
]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Buildroot commit [1] introduced a new Buildroot-Initialize.cmake file,
to mimic the upstream Linux-Initialize.cmake.
However, this upstream file was introduced in commit [2], which was
introduced in CMake 3.27.
When compiling a cmake package on a host with a cmake older than
version 3.27 (for example, the Buildroot Docker reference image has
cmake 3.25), the configuration fails with the error:
CMake Error at /buildroot/output/host/share/buildroot/Platform/Buildroot-Initialize.cmake:1 (include):
include could not find requested file:
Platform/Linux-Initialize
Call Stack (most recent call first):
/usr/share/cmake-3.25/Modules/CMakeSystemSpecificInitialize.cmake:21 (include)
CMakeLists.txt:20 (project)
CMake version < 3.27 is setting its LINUX predefine elsewhere (see
commit log of [1]), so this commit fixes the issue by simply making
the include optional. This will guarante thee cmake predefines will
be present in all the cases.
Fixes:
[1]
[1] ef9f0a07ed
[2] cc737ae829
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The old URL now leads to an HTTP 404 not found error.
Update it to the new one which contains the hashes for the current
release as well as older ones.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
The current 'install' target comprises 'install-libs', 'install-apps'
and 'install-docs'.
In our case we don't want to install documentation to the target, so
just run the other two.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
It should be noted that because the python bindings have wrong default
include dirs, they are useless if the includes are not provided
externally.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
When BR2_UCLIBC_INSTALL_UTILS is enabled, utils such as getconf, ldd,
locale get installed to TARGET_DIR. However, they do not get installed
to STAGING_DIR, which is annoying as it means that they are not part
of external toolchains built by Buildroot.
This commit adjusts the uclibc package to make sure those tools also
get installed to STAGING_DIR.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The UCLIBC_INSTALL_UTILS_STAGING is really badly named, as it doesn't
install anything to STAGING_DIR. Instead, it installs the host variant
of ldd and ldconfig into $(HOST_DIR)/bin. Therefore, rename it to
UCLIBC_INSTALL_HOST_UTILS.
This is important as a follow-up commit will re-introduce a
UCLIBC_INSTALL_UTILS_STAGING variable which really installs things
into STAGING_DIR.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Upstream is dead, website unreachable, and the use case in 2026 is
dubious, so drop the package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The ukify tool can be used to create Unified Kernel Images.
Signed-off-by: Bram Vlerick <bram.vlerick@openpixelsystems.org>
[Arnout:
- Remove the target option.
- Use enabled/disabled instead of true/false.
- Always enable for host build.
- Add dependency on host-python-pefile.
]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
When building system binaries you may not even want TCG support if you
are only intending to use KVM. Provide the options so the user can
select only what they need.
With only KVM selected the QEMU build will generally only build the
binary for your target system. We keep TCG support on by default so as
not to break existing defconfigs.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Although it is possible to configure an AArch64 CPU without support
for EL2 in practice all the common AArch64 have supported
virtualisation from the start.
If we really wanted to be strict we could blacklist known non-EL2 CPUs
but AFAICT all the current ones in the config have EL2.
I should also note KVM on Arm is deprecated and was removed from the
kernel in v6.10.
Reviewed-by: Jesse Taube <jesse@rivosinc.com>
Reviewed-by: Thomas Huth <huth@tuxfamily.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The current generated cJSONConfig.cmake holds hard coded path of libraries and makes it impossible to use in SDKs.
Use CMakePackageConfigHelpers and @PACKAGE_INIT@ to make them suit for real environment dynamically.
Signed-off-by: Guillaume Chaye <guillaume.chaye@zeetim.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The .mk file currently states:
If LWS_MAX_SMP=1, then there is no code related to pthreads
compiled in the library. If unset, LWS_MAX_SMP defaults to 32 and a
small amount of pthread mutex code is built into the library.
However, this is incorrect: when unset, LWS_MAX_SMP is actually set to
1, so mutexes aren't built in.
To fix, set it to 32 explicitly when threads are enabled. Why 32?
Because
https://libwebsockets.org/lws-api-doc-master/html/md_README.coding.html
states:
You can control the context basic data allocation for
multithreading from Cmake using -DLWS_MAX_SMP=, if not given it's
set to 32.
Signed-off-by: Bart Van Severen <bart.vanseveren@barco.com>
Signed-off-by: Thomas Devoogdt <thomas.devoogdt@barco.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When given a certificate directory with --with-ca-path, curl doesn't
list the files in that directory. Instead, it uses the certificate hash
to directly open the requested CA certificate. Therefore, putting a
bundle in that directory and removing all the individual certificates is
not possible.
In order to support use of the bundle, a separate configuration option
--with-ca-bundle is needed. With this option, it is possible to remove
the individual certificates and include just the bundle, which reduces
the size of the root filesystem a bit.
Note that the bundle is generated by the ca-certificates package, which
also installs the individual certificates and the hash symlinks. It
keeps both individual certificates and the bundle in the target.
Signed-off-by: Lance Fredrickson <lancethepants@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
