Commit b55957fa65 ("CHANGES: Update for 2025.02.3" added an entry for
2025.02.3, but forgot to add an empty line after the title. Fix that.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit f30bf62f53 ("CHANGES: update for 2025.02.4") added the release to
the top of the file instead of below 2025.05-rc1. Fix that and indent with
a tab like the other releases.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since this package hasn't had a proper release in a while this patch set
the CPE_VERSION and CPE_UPDATE to the latest tags available.
The annotation available on NVD all refers to this last available
version `cpe:2.3:a:luajit:luajit:2.1.0:beta3:*:*:*:*:*:*`.
See https://nvd.nist.gov/vuln/detail/CVE-2020-15890 for instance.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is a temporary fix under discussion [1], but it resolves the
problem, by implementing the same behavior as GCC 14.x for register
allocation on Microblaze.
Tested with qemu_microblazeel_mmu_defconfig and used to generate
Microblaze toolchains for the Bootlin toolchains 2025.08-1 [2].
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432#c10
[2] 83947c7bb6
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch adds atomic test and set support for the microblaze arch. A patch
is required to use atomic test and set with gcc 14 and 15 which has been
submitted upstream.
To test this patch with gcc 14:
$ cat > .config<<EOF
BR2_microblazeel=y
BR2_GCC_VERSION_14_X=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PACKAGE_ACPITOOL=y
EOF
$ make olddefconfig
$ make
To test this patch with gcc 15:
$ cat > .config<<EOF
BR2_microblazeel=y
BR2_GCC_VERSION_15_X=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PACKAGE_ACPITOOL=y
EOF
$ make olddefconfig
$ make
Fixes: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118280
Upstream: https://patchwork.ozlabs.org/project/gcc/list/?series=466193
Signed-off-by: Neal Frager <neal.frager@amd.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The company name was changed from "benetti-engineering-sas" to "benetti-engineering"
to be agnostic to the company legal form. Update all GitHub and LinkedIn links
accordingly.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The toolchains have been rebuilt with a recent Buildroot, and are
based on:
- Stable toolchains:
GCC 14.3
Binutils 2.43.1
GDB 15.2
Linux headers 5.4
glibc 2.41
musl 1.2.5
uclibc-ng 1.0.45
- Bleeding edge toolchains
GCC 15.1
Binutils 2.44
GDB 16.3
Linux headers 5.15
glibc 2.41
musl 1.2.5
uclibc-ng 1.0.45
The microblaze bleeding-edge toolchains are back, since we integrated
the "atomic issue" fix.
All tests are successful:
https://gitlab.com/tpetazzoni/buildroot/-/pipelines/1976388296
(note: the test branch had one more commit doing tweaks on the wget
option and re-enabling the backup site for unit tests, which are
needed to avoid intermittent failures of Gitlab CI jobs)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This issue has been fixed in the Bootlin toolchains thanks to the
Microblaze "atomic fix" in GCC.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The AUTORECONF variable was introduced in commit [1] with reference to
the patches that modified the m4 and Makefile.am files.
The commit [2] removed the last such patch but left the reference to the
patch and the AUTORECONF variable.
Later, commit [3] updated the mirror to the gitlab URL that no longer
bundle a pre-generated `configure` file, making the execution of
AUTORECONF necessary anyway.
This patch removes the obsolete reference to the patch 0001 removed in
[2] to avoid ambiguity with the new patch 0001 introduced in commit [4].
[1] 01a82c1401 package/libapparmor: enable python bindings
[2] 27cd0b5033 package/apparmor: bump to version 3.0.4
[3] 5649202ddc package/libapparmor: bump to version 3.1.7
[4] 2640f5dcd0 package/libapparmor: fix build w/ musl
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
[Peter: add a comment explaining why]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the package bump to v10.05.0 the xlib libraries detection has been
improved to error missing x libraries (see [2]).
The following error is happening on the autobuilder when building
ghostscript with xlib_libX11:
```
checking for XOpenDisplay in -lX11... yes
checking for XdbeQueryExtension in -lXext... yes
checking for XtAppCreateShell in -lXt... no
configure: error: X11 libraries (libX11, libXt, libXext) not available, either install them, or rerun configure with "--without-x"
make: *** [package/pkg-generic.mk:263: /home/buildroot/instance-0/output-1/build/ghostscript-10.05.1/.stamp_configured] Error 1
```
This error can be reproduced with the following config:
```
cat <<EOF >.config
BR2_arm=y
BR2_cortex_a7=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_XORG7=y
BR2_PACKAGE_XLIB_LIBX11=y
BR2_PACKAGE_GHOSTSCRIPT=y
EOF
make olddefconfig
make
```
This patch fixes the xlib dependencies of the ghostscript package to
correctly build with X support:
- The 'XtAppCreateShell' function is provided by the package
'xlib_libXt'.
- The 'XdbeQueryExtension' function is provided by the package
'xlib_libXext'.
They both select the 'xlib_libX11' package.
[1] 9abf662cfd package/ghostscript: security bump to version 10.05.0
[2] 37eede31e1
Fixes: https://autobuild.buildroot.org/results/45d/45d0414f341feb2354478b145396fe137f9cc6a6
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
daemon provides its own getopt() declaration for non-GNU libcs. This
declaration is compatible with musl provided one with C standards before
C23. GCC 15 defaults to C23 that makes the empty params declaration
equivalent to getopt(void), which is incompatible with musl declaration.
Set C standard to gnu99 to restore the previous behaviour.
Fixes:
https://autobuild.buildroot.org/results/cc3311c86e2b14bf9a9c1ea00056e0b290ec11a3
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
GCC 15 switched to C23 by default, which made "void foo()" equivalent to
"void foo(void)". This causes a build error because init_comm() doesn't
actually take any arguments.
Signed-off-by: Florian Larysch <fl@n621.de>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Add a patch fixing cmake 4 compatibility, found in upstream pull
request #349. The patch has been modified to apply on version 0.6.1
instead of the current upstream HEAD.
Signed-off-by: Benoît Monin <benoit.monin@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Since the commit [1] the janet package started failing on the
autobuilder when using musl libc:
```
[50/56] Compiling C object libjanet.so.1.35.2.p/meson-generated_.._janet.c.o
FAILED: libjanet.so.1.35.2.p/meson-generated_.._janet.c.o
/workdir/instance-0/output-1/host/bin/armeb-buildroot-linux-musleabi-gcc -Ilibjanet.so.1.35.2.p -I. -I.. -I../src/include -fdiagnostics-color=always -Wall -Winvalid-pch -std=c99 -O3 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O1 -g3 -fPIC -pthread -fvisibility=hidden -MD -MQ libjanet.so.1.35.2.p/meson-generated_.._janet.c.o -MF libjanet.so.1.35.2.p/meson-generated_.._janet.c.o.d -o libjanet.so.1.35.2.p/meson-generated_.._janet.c.o -c janet.c
src/core/util.c: In function 'janet_strerror':
src/core/util.c:977:12: error: returning 'int' from a function with return type 'const char *' makes pointer from integer without a cast [-Wint-conversion]
[51/56] Compiling C object janet-native.p/meson-generated_.._janet.c.o
```
The commit [2] introduced the issue in v1.35.0, the `strerror` function
has different definition on glibc compared to musl. This issue has been
addressed in commit [3]. This patch add the upstream commit [3].
[1] 31212c4c58 package/janet: bump to version 1.35.2
[2] 8334504f4e
[3] a5d6b22838
Fixes: https://autobuild.buildroot.org/results/ff1/ff1d6063c1a79d17cfa9910cca824e704a4a0c67/build-end.log
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
- add option for iwmon support
- enable linux kernel CONFIG_NLMON option needed for iwmon
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since tuxfamily.org is slowly fading away, update my mail address
to something that is more future-proof.
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Signed-off-by: Julien Olivain <ju.o@free.fr>
On the autobuilder the following build error would appear for the
libzenoh-pico package when the option BR2_ENABLE_RUNTIME_DEBUG is
enabled:
```
[ 1%] Building C object CMakeFiles/zenohpico_shared.dir/src/api/encoding.c.o
In function '_z_encoding_convert_into_string',
inlined from 'z_encoding_to_string' at /workdir/instance-0/output-1/build/libzenoh-pico-1.2.1/src/api/encoding.c:261:5:
/workdir/instance-0/output-1/build/libzenoh-pico-1.2.1/src/api/encoding.c:203:15: error: 'strncat' output truncated before terminating nul copying 1 byte from a string of the same length [-Werror=stringop-truncation]
203 | (void)strncat(value, &sep, 1);
| ^~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
```
This error can be reproduced with:
```
cat >.config <<EOF
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_LIBZENOH_PICO=y
BR2_ENABLE_RUNTIME_DEBUG=y
EOF
make olddefconfig
make libzenoh-pico
```
This patch include the upstream commit [1] that fixes this issue.
[1] 60e635cbb1
Fixes: https://autobuild.buildroot.org/results/0c4/0c4644b17646d3ec482f0a4cf02d6fde19db2c99
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
When the package was introduced in [1], it lacked a kconfig comment
indicating that it requires a toolchain with thread support.
[1] ea1cc1af55 package/cpuinfo: new package
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
On autobuilder config with BR2_TOOLCHAIN_HAS_THREADS not set the
following error happens when building the pthreadpool package:
```
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - not found
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - no
CMake Error at /home/buildroot/instance-0/output-1/host/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
Could NOT find Threads (missing: Threads_FOUND)
Call Stack (most recent call first):
/home/buildroot/instance-0/output-1/host/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE)
/home/buildroot/instance-0/output-1/host/share/cmake-3.31/Modules/FindThreads.cmake:226 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:143 (FIND_PACKAGE)
-- Configuring incomplete, errors occurred!
```
This can be reproduced with:
```
cat >.config <<EOF
BR2_armeb=y
BR2_TOOLCHAIN_BUILDROOT_UCLIBC=y
BR2_PTHREADS_NONE=y
BR2_PACKAGE_PTHREADPOOL=y
EOF
make olddefconfig
make pthreadpool
```
Since the introduction of this package in [1], the dependency was not
included. Since this package was part of the tensorflow-lite
dependencies that required thread it was not an issue.
This patch adds BR2_TOOLCHAIN_HAS_THREADS in the dependency to avoid
errors when built as a standalone package.
[1] f2486a6cf9 package/pthreadpool: new package
Fixes: https://autobuild.buildroot.org/results/35a/35aa100d72c6875350ad10c57f028f04052cbf79
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
The following error occur on the autobuilder for static build using
buildroot toolchain and uclibc:
```
/usr/bin/make -j17 -C /home/buildroot/instance-0/output-1/build/snooze-0.5/ PREFIX=/usr CC=/home/buildroot/instance-0/output-1/host/bin/arc-buildroot-linux-uclibc-gcc CFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g0 -static -static"
make[1]: Entering directory '/home/buildroot/instance-0/output-1/build/snooze-0.5'
/home/buildroot/instance-0/output-1/host/bin/arc-buildroot-linux-uclibc-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g0 -static -static snooze.c -o snooze
snooze.c:22:10: fatal error: sys/auxv.h: No such file or directory
22 | #include <sys/auxv.h>
| ^~~~~~~~~~~~
compilation terminated.
make[1]: *** [<builtin>: snooze] Error 1
```
This error can be reproduced with:
```
cat >.config <<EOF
BR2_arm=y
BR2_cortex_a7=y
BR2_TOOLCHAIN_BUILDROOT_UCLIBC=y
BR2_STATIC_LIBS=y
BR2_PACKAGE_SNOOZE=y
EOF
make olddefconfig
make snooze
```
The error doesn't occur on external toolchains.
The `#include <sys/auxv.h>` was orinally included in the initial commit
(see [1]) to use the `getauxval` function declaration. This function
usage has since been removed in commit [2].
This patch removes the include that is no longer needed.
[1] 5648088197
[2] 610e6b35ec
Fixes: https://autobuild.buildroot.org/results/aec/aec463f87094a47ee059113f08e8ee3604dcea9b
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Reviewed-by: J. Neuschäfer <j.ne@posteo.net>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
When building tini with musl libc, the following error occurs dur to
missing declaration of 'basename':
```
/home/buildroot/instance-0/output-1/build/tini-0.19.0/src/tini.c: In function 'print_usage':
/home/buildroot/instance-0/output-1/build/tini-0.19.0/src/tini.c:227:36: error: implicit declaration of function 'basename' [-Wimplicit-function-declaration]
227 | fprintf(file, "%s (%s)\n", basename(name), TINI_VERSION_STRING);
| ^~~~~~~~
make: *** [package/pkg-generic.mk:273: /home/buildroot/instance-0/output-1/build/tini-0.19.0/.stamp_built] Error 1
make: Leaving directory '/home/buildroot/instance-0/buildroot'
```
This error can be reproduced with:
```
cat >.config <<EOF
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_MUSL_BLEEDING_EDGE=y
BR2_PACKAGE_TINI=y
EOF
make olddefconfig
make tini
```
This patch adds the upstream commit [1], that fixes this issue by
including `libgen.h`.
[1] 924c4bd602
Fixes: https://autobuild.buildroot.org/results/f0d/f0d10cd25f3b0e2a4af7266f7417b339ea5d242a
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
The php-pecl-dbus encouters two build issues in both buildroot 2025.02.x
and master branch, both related to PHP8 and GCC14:
/home/alexis/src/buildroot/php/build/php-pecl-dbus-b147624d480c3353e6c700e9a2d0c6f14d853941/dbus.c:465:56:
error: assignment to ‘zend_object_get_properties_t’ {aka ‘struct
_zend_array * (*)(struct _zend_object *)’} from incompatible pointer
type ‘HashTable * (*)(zval *)’ {aka ‘struct _zend_array * (*)(struct
_zval_str
uct *)’} [-Wincompatible-pointer-types]
465 | dbus_object_handlers_dbus_array.get_properties =
dbus_array_get_properties;
| ^
[...]
The build failure can be reproduced with this 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_PHP=y
BR2_PACKAGE_PHP_PECL_DBUS=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 and zend_hash_get_current_key(see [1]).
But at this time, php-dbus 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])
Bring the relevant patches to fix this build.
The first patch comes from an already opened PR on the upstream source.
The second patch has been written during the build failure
investigation, and has been sent upstream as well.
Fixes: https://autobuild.buildroot.net/results/e9892bbefa781b403fd3d834b6c48527c8e078ba
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
All Go packages must depend on BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS,
which ensures that we do have a Go compiler available for that target.
BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS is currently restricted to the
availability of a full host Go compiler bootstrap. However, there are
architectures like AArch64 for which a full bootstrap is not supported.
Thus, currently, on an AArch64 host, we can't build Go packages (for
target or host), because we can't bootstrap a Go compiler.
However, note that a single Go compiler can generate code for all the
architectures supported by Go and for some host architectures, there are
pre-built toolchains available. When host-go-bin was added in commit
7b2a164b74 ("package/go/go-bin: new host-go provider"), the host
dependency was properly accounted for: It is already possible to build
host-go packages with go-bin. However, the fact that a Go compiler, in
addition to its native target, can also generate code for all supported
architectures, was missed at the time.
Thus, we can fix this problem by relaxing the condition under which
BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS is set to allowing go-bin
along with go-bootstrap. This allows a situation where the host can't
bootstrap, but for which there is a pre-built toolchain to build Go
packages for a supported target.
Signed-off-by: Florian Larysch <fl@n621.de>
Cc: Yann E. MORIN <yann.morin@orange.com>
Cc: Romain Naour <romain.naour@smile.fr>
Reviewed-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
The previous method used to determine the --gcc-install-dir relied on
'ls' over the gcc installation path, which was fragile and failed in
cases where the external toolchain contained multiple gcc versions or
paths [1].
We replace it a more reliable approach using:
$(TARGET_CC) -print-search-dirs
This helps setup to register the desired GCC architecture if a
given toolchain packages includes multiple GCC architecture
installations. Which isn't possible using the actual method using 'ls'.
For example from James's report:
└── /opt/container/my-toolchain-2025.01.01.12345/lib/gcc/
├── aarch64-example-linux-gnu/
│ └── ...
├── i686-example-linux-gnu/
│ └── ...
└── x86_64-example-linux-gnu/
└── ...
Thanks to Romain Naour for suggesting this improved method.
[1] https://lore.kernel.org/buildroot/d1c773dc-8346-4077-946a-0d3b4e30a6c8@smile.fr/T/#t
Reported by: James Knight <git@jdknight.me>
Signed-off-by: El Mehdi YOUNES <elmehdi.younes@smile.fr>
Tested-by: James Knight <jdknight@jdknight.me>
Tested-by: James Knight <git@jdknight.me>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
When a br2-external tree has no defconfig, list-defconfig currently
whines with an error from find:
find: ‘[...]/my-external/configs’: No such file or directory
Fix that by only running find if the directory exists.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
When a br2-external tree description contains an odd number of single
quotes, list-defconfigs will fail with a shell error message:
/bin/sh: -c: line 1: unexpected EOF while looking for matching `"'
make[1]: *** [Makefile:1243: list-defconfigs] Error 2
Whoever wrote that code will have to write this sentence 100 times
on the blackboard:
Never, ever pass user-provided data in a printf format.
(see commit 49117c1028 (core: support description for br2-external
trees); dang, I knew it... And I should have known better when I wrote
that code, damit...)
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Grout automatically creates a TUN interface at runtime, so the target
kernel must have CONFIG_TUN enabled. Add a fix-up to ensure that option
is selected.
Signed-off-by: Maxime Leroy <maxime@leroys.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Toolchain failed to bootstrap with LP64F and LP64S ABIs.
As reported by Julien in [1]:
Testing the "lp64f" ABI with commands:
cat >.config <<EOF
BR2_loongarch64=y
BR2_LOONGARCH_FPU_32=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF=y
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set
EOF
make olddefconfig
make
fails in host-gcc-initial with output:
Assembler messages:
/tmp/ccEkwSsD.s:28: Error: register save offset not a multiple of 8
/tmp/ccEkwSsD.s:30: Error: register save offset not a multiple of 8
/tmp/ccEkwSsD.s:50: Error: register save offset not a multiple of 8
See also autobuilder failures such as [2].
Testing the "lp46s" ABI with commands:
cat >.config <<EOF
BR2_loongarch64=y
BR2_LOONGARCH_FPU_NONE=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
BR2_LINUX_KERNEL_NEEDS_HOST_LIBELF=y
BR2_TARGET_ROOTFS_EXT2=y
# BR2_TARGET_ROOTFS_TAR is not set
EOF
make olddefconfig
make
fails in host-gcc-final with output:
/buildroot/output/host/loongarch64-buildroot-linux-gnusf/bin/ld: cannot find crti.o: No such file or directory
/buildroot/output/host/loongarch64-buildroot-linux-gnusf/bin/ld: cannot find -lc: No such file or directory
/buildroot/output/host/loongarch64-buildroot-linux-gnusf/bin/ld: cannot find crtn.o: No such file or directory
See also autobuilder failures with as [3].
This commit marks those ABIs as broken at the moment to allow time
for investigation. Also, since gcc defaults to the "lp64d" ABI which
requires a 64bit FPU is present, the BR2_LOONGARCH_FPU_32 and
BR2_LOONGARCH_FPU_NONE options also needs to be marked as broken
as well. See [4].
[1] https://lore.kernel.org/buildroot/e17da108d1fb4e6abda26445dc053b35@free.fr/
[2] https://autobuild.buildroot.org/results/f98570293823867e6c43a1672e1a4b43ca1e4be5
[3] https://autobuild.buildroot.org/results/cf56c37fabcae964dbf4f96eb43a7e4d964452b6
[4] https://lore.kernel.org/buildroot/7b0f1cb629fce8a57d9b644b8beb8b2a@free.fr/
Cc: Mingcong Bai <jeffbai@aosc.io>
Cc: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
[Julien:
- add link to mailing list discussion
- add configuration to reproduce issues to help future investigations
- add links to autobuilder failures in commit log
- mark BR2_LOONGARCH_FPU_{32,NONE} as broken
]
Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Version 95be71b matches with kernel 6.12.41.
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Tested-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
[Fiona: tested on CM4 and Zero 2W, with the RPi bootloader
booting into U-Boot]
Signed-off-by: Julien Olivain <ju.o@free.fr>
When building a toolchain with kernel headers 6.1.x, the build fail
due to missing hash for linux-6.1.147.tar.xz
The hash was removed by mistake when bumping kernel 6.{6, 12, 15}.x
series.
Fixes: 51b27bad91
Cc: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
When building the libapparmor package with musl the following error
would appear:
```
test_multi.c: In function 'main':
test_multi.c:27:30: error: implicit declaration of function 'basename' [-Wimplicit-function-declaration]
27 | printf("File: %s\n", basename(argv[1]));
| ^~~~~~~~
test_multi.c:27:24: warning: format '%s' expects argument of type 'char *', but argument 2 has type 'int' [-Wformat=]
27 | printf("File: %s\n", basename(argv[1]));
| ~^ ~~~~~~~~~~~~~~~~~
| | |
| | int
| char *
| %d
make[3]: *** [Makefile:466: test_multi_multi-test_multi.o] Error 1
```
This error can be reproduced with the following:
```
cat >.config <<EOF
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_MUSL_BLEEDING_EDGE=y
BR2_PACKAGE_LIBAPPARMOR=y
EOF
make olddefconfig
make libapparmor
```
On musl libc the function `basename` is provided by included libgen.h.
This error has been addressed upstream in [1] by re-defining the
function `basename`.
[1] 7fb040bde6
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
[Peter: drop unrelated AUTORECONF change]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following vulnerability:
- CVE-2025-8177
A vulnerability was found in LibTIFF up to 4.7.0. It has been rated as
critical. This issue affects the function setrow of the file
tools/thumbnail.c. The manipulation leads to buffer overflow. An
attack has to be approached locally. The patch is named
e8c9d6c616b19438695fd829e58ae4fde5bfbc22. It is recommended to apply a
patch to fix this issue. This vulnerability only affects products that
are no longer supported by the maintainer.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2025-8177
- https://gitlab.com/libtiff/libtiff/-/merge_requests/737
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following vulnerability:
- CVE-2025-8176
A vulnerability was found in LibTIFF up to 4.7.0. It has been declared
as critical. This vulnerability affects the function get_histogram of
the file tools/tiffmedian.c. The manipulation leads to use after free.
The attack needs to be approached locally. The exploit has been
disclosed to the public and may be used. The patch is identified as
fe10872e53efba9cc36c66ac4ab3b41a839d5172. It is recommended to apply a
patch to fix this issue.
For more information, see:
- https://www.cve.org/CVERecord?id=CVE-2025-8176
- https://gitlab.com/libtiff/libtiff/-/merge_requests/727
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
On my laptop (i5-8365U), running cross-tesseract-ocr in QEMU takes
longer than the default timeout (5s), causing the test to fail:
# time tesseract frame10.png output
Error in pixReadMemTiff: function not present
Error in pixReadMem: tiff: no pix returned
Error in pixaGenerateFontFromString: pix not made
Error in bmfCreate: font pixa not made
Estimating resolution as 157
real 0m 8.17s
user 0m 5.36s
sys 0m 2.79s
So extend the assertRunOk() timeout with ~2x that similar to how it is done
for the gst-launch-1.0 pipeline.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
