With highly parallel builds on a heavily loaded machine, the libopenssl
build often (about half of the time) fails with spurious missing rules
in its Makefile:
>>> host-libopenssl 3.4.1 Installing to host directory
[...] /usr/bin/make -C [...]/build/host-libopenssl-3.4.1 install
"/usr/bin/make" depend && "/usr/bin/make" _build_libs
"/usr/bin/make" depend && "/usr/bin/make" _build_modules
"/usr/bin/make" depend && "/usr/bin/make" _build_programs
[...]
make[3]: *** No rule to make target '_build_modules'. Stop.
make[2]: *** [Makefile:3159: build_modules] Error 2
make[2]: *** Waiting for unfinished jobs....
make[3]: Nothing to be done for '_build_programs'.
make[3]: Nothing to be done for '_build_libs'.
make[1]: *** [package/pkg-generic.mk:283: [...]/build/host-libopenssl-3.4.1/.stamp_host_installed] Error 2
make[1]: *** Waiting for unfinished jobs....
[...]
make: *** [Makefile:23: _all] Error 2
Ideally, we'd like to fix the issue. However, the Nakefile is generated
by the Configure script, written in perl, from the template in
Configurations/unix-Makefile.tmpl, which also uses some kind of special
(perl-related, probably) templating language. That makes it pretty
difficult to see what is going on, though, and nigh impossible to fix
without a deep understanding of the openssl buildsystem.
So, we can only disable parallel builds until the issue is fixed
upstream [0]. Add a comment to both build commands (host and target) to
reference the upstream issue report.
Note that the issue has mostly been observed in the build of the host
variant so far, but there is no reason why it can't happen in the build
of the target variant.
[0] https://github.com/openssl/openssl/issues/27074
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes http://autobuild.buildroot.net/results/6efc1275d3aac9f0a4c000f3d0911b5a880e495d/
Rauc uses X509_PURPOSE_get_by_id() since rauc-1.3 with commit 375dbb16dd94
("src/signature: add support for codesigning certificate purpose"):
../src/signature.c: In function 'signature_init':
../src/signature.c:97:13: warning: implicit declaration of function 'X509_PURPOSE_get_by_id'; did you mean 'X509_PURPOSE_get_id'? [-Wimplicit-function-declaration]
97 | if (X509_PURPOSE_get_by_id(id) >= 0) {
Which is not provided by LibreSSL:
nm -D target/usr/lib/libcrypto.so | grep X509_PURPOSE_
00000000001377b0 T X509_PURPOSE_get0
0000000000137850 T X509_PURPOSE_get0_name
0000000000137860 T X509_PURPOSE_get0_sname
00000000001377d0 T X509_PURPOSE_get_by_sname
00000000001377a0 T X509_PURPOSE_get_count
0000000000137840 T X509_PURPOSE_get_id
So force the use of libopenssl.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since glibc bump to 2.41 in Buildroot commit [1], rt-tests is failing
to build with error:
In file included from src/lib/rt-utils.c:28:
src/include/rt-sched.h:45:8: error: redefinition of 'struct sched_attr'
45 | struct sched_attr {
| ^~~~~~~~~~
glibc 2.41 adds sched_*attr, conflicting with rt-sched.h in the rt-tests
package. This commit resolves the conflict by applying a patch from
upstream which excludes the conflicting code when using glibc >= 2.41.
Fixes:
https://autobuild.buildroot.org/results/30308c74291004c328d6c3603ce68d600c5ef281/
[1] https://gitlab.com/buildroot.org/buildroot/-/commit/6ecab31fad12a494ec0d2a3767c736a55c80a769
Signed-off-by: Brandon Lumbra <brandon.lumbra@sense.com>
[Julien:
- add extra info in commit log
- add missing Signed-off-by line in commit log
- add missing Signed-off-by in patch
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
We moved the issue tracking to gitlab some time ago. Adjust the bug tracker
references in news.html to point to there instead of bugzilla for clarity.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Postgresql fails to build with NLS enabled against uclibc/musl after the
move to meson:
-------------------------------------------------------
/home/autobuild/autobuild/instance-13/output-1/host/lib/gcc/aarch64-buildroot-linux-uclibc/12.4.0/../../../../aarch64-buildroot-linux-uclibc/bin/ld: scram-common.c:(.text+0x65c): undefined reference to `libintl_gettext'
/home/autobuild/autobuild/instance-13/output-1/host/lib/gcc/aarch64-buildroot-linux-uclibc/12.4.0/../../../../aarch64-buildroot-linux-uclibc/bin/ld: scram-common.c:(.text+0x6cc): undefined reference to `libintl_gettext'
/home/autobuild/autobuild/instance-13/output-1/host/lib/gcc/aarch64-buildroot-linux-uclibc/12.4.0/../../../../aarch64-buildroot-linux-uclibc/bin/ld: scram-common.c:(.text+0x73c): undefined reference to `libintl_gettext'
-------------------------------------------------------
uclibc/musl toolchains use GNU gettext for NLS support.
So we need to link against external libintl.
Fixes: https://autobuild.buildroot.org/results/244f154aece46d02747b875faba4c51e7b5d0dc2/
Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
[Peter: also pass TARGET_LDFLAGS, mention the change to meson]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The COMPILER_RT_STANDALONE_BUILD parameter was passed twice. One time as
FALSE and immediately after as TRUE which overrides previous value, so drop
the first one.
Signed-off-by: Yevhen Babiichuk (DustDFG) <dfgdust@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For consistency with the other host packages.
Signed-off-by: Yevhen Babiichuk (DustDFG) <dfgdust@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes:
http://autobuild.buildroot.net/results/ec3de790a66373f270f731519e2ef51c293ba683/
Currently it's not possible to build strace on m68k when using
musl because the version of musl in buildroot doesn't have the
m68k specific definitions of POLLWRNORM and POLLWRBAND.
This is already fixed upstream so manually apply the patch
until the next release.
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
[Peter: add autobuilder ref and upstream link / s-o-b in patch description]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since SQLite 3.38 [0] the JSON extension is enabled by default.
A new Option was introduced to actively disable the extension. [1]
The JSON support is very small (<4%) compared to the rest of sqlite, so
enable it unconditionally:
-rwxr-xr-x 1 peko peko 1470368 Mar 12 10:50 output-without/target/usr/lib/libsqlite3.so.0.8.6
-rwxr-xr-x 1 peko peko 1530232 Mar 12 10:46 output-with/target/usr/lib/libsqlite3.so.0.8.6
E.G. a delta of 59864 bytes or 3.9%
[0] https://sqlite.org/releaselog/3_38_0.html
[1] https://sqlite.org/json1.html#compiling_in_json_support
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
[Peter: unconditionally include JSON support]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The hack to force big endian support when building
for a big endian machine doesn't work as there is
some whitespace between "#" and "undef" in config.h.
Add a wildcard between those two so that the target
line matches and the replacement is done.
Allows me to play DOOM on my LC475.
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When util-linux is compiled with the uuidd daemon and with systemd
init, the rootfs creation fails in fakeroot as follows:
printf 'host/bin/systemctl --root=build/buildroot-fs/ext2/target preset-all\n' >> build/buildroot-fs/ext2/fakeroot
[...]
FAKEROOTDONTTRYCHOWN=1 host/bin/fakeroot -- build/buildroot-fs/ext2/fakeroot
rootdir=build/buildroot-fs/ext2/target
table='build/buildroot-fs/full_devices_table.txt'
ignored spec: h /var/log/journal/%m - - - - +C
ignored spec: x /var/tmp/systemd-private-%b-*
ignored spec: X /var/tmp/systemd-private-%b-*/tmp
ignored spec: x /var/lib/systemd/coredump/.#core*.%b*
ignored spec: z /var/log/journal/%m 2755 root systemd-journal - -
ignored spec: z /var/log/journal/%m/system.journal 0640 root systemd-journal - -
<stdin>:37: Failed to resolve user 'uuidd': No such process
make[1]: *** [fs/ext2/ext2.mk:66: images/rootfs.ext2] Error 65
make: *** [Makefile:83: _all] Error 2
This error can be reproduced with the commands:
cat <<EOF >.config
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_UTIL_LINUX=y
BR2_PACKAGE_UTIL_LINUX_UUIDD=y
BR2_INIT_SYSTEMD=y
BR2_TARGET_ROOTFS_EXT2=y
EOF
make olddefconfig
make
The error comes from systemctl, which cannot find the uuidd user in
the target rootfs, needed in the uuidd.service unit file [1].
This commit fixes the issue by adding the uuidd user and group in
support/scripts/mkusers syntax.
[1] https://web.git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/misc-utils/uuidd.service.in?h=v2.40.2
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
[Julien: add commands to reproduce the issue in commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Fixes the following security issue:
CVE-2023-46361: Artifex Software jbig2dec v0.20 was discovered to
contain a SEGV vulnerability via jbig2_error at /jbig2dec/jbig2.c.
https://www.cve.org/CVERecord?id=CVE-2023-46361
Note that jbig2dec version 0.19 (used in Buildroot 2024.02.11) is not
officially listed as affected, but it actually has the same bug.
Also note that this CVE is about a crash in the CLI tool only.
Signed-off-by: Raphaël Mélotte <raphael.melotte@mind.be>
[Julien: add JBIG2DEC_IGNORE_CVES]
Signed-off-by: Julien Olivain <ju.o@free.fr>
cpe:2.3:o:linaro:op-tee:4.3.0:*:*:*:*:*:*:* is a valid CPE ID.
See:
https://nvd.nist.gov/products/cpe/detail/2754E8CF-9BD5-448D-9F32-CFAC92278CD9
Note: this commit needs to set _CPE_ID_PREFIX because optee-os CPE
"part" needs to be set to "o" (OS), while the default Buildroot prefix
is "a" (Application).
Signed-off-by: Daniel Lang <dalang@gmx.at>
[Julien:
- add extra info in commit log (and fix CVE to CPE)
- add a new line after OPTEE_OS_CPE_ID_PRODUCT for readability
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
By default, use an indent of 2, which is the same as what 'jq' uses.
This omits the need for 'jq' in the example usage. Also, add a new
line to the output while at it.
Signed-off-by: Thomas Devoogdt <thomas.devoogdt@barco.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
As the mender_x86_64_efi_defconfig does not build the xz package, creating a
boostrap image with a lzma compression results in the following error on boot:
```
Error while handling bootstrap Artifact, continuing: invalid bootstrap
Artifact: readHeaderV3: handleHeaderReads: readHeader: readNext: Failed to get
next header: reader: error reading archive: unexpected EOF
```
This also results in the same error for the generated mender image, as it's
also created with lzma compression unconditionally.
Set the compression to none to resolve the above error.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Currently, the post-build.sh script adds device_type to /var/lib/mender,
however, this doesn't work for two reasons:
1) /data/ mounts to /var/lib/mender
2) The device_type location in mender.conf points to /etc/mender/device_type.
This leads to an error during the bootstrap process because mender reads the
default device_type file installed by mender.mk in /etc/mender, leading to the
following error:
```
Error while handling bootstrap Artifact, continuing: invalid bootstrap
Artifact: readHeaderV3: handleHeaderReads: image
(device types [buildroot-x86_64]) not compatible with device BUILDROOT_DEVICE
```
Set the creation of the device_type file in board/mender/x86_64/post-build.sh
to /etc/mender/device_type to fix the error.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
systemd automatically creates tmpfs mounts for /tmp, /run, /dev/shm, and
others. If tmpfs is not enabled in the kernel, systemd crashes with an
unknown filesystem error on boot. This hasn't manifested itself during
tests with defconfigs such as pc_x86_64_efi_defconfig for a few reasons:
- No defconfig uses systemd as the init system by default
- Even if a user does use pc_x86_64_efi_defconfig and changes to systemd,
the board/pc/linux.config file enables CONFIG_PCI, which selects
CONFIG_TMPFS.
- The systemd init tests use a prebuilt kernel with tmpfs enabled.
Enable tmpfs unconditionally to ensure that systemd always boots, even with
a minimal kernel built.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The DRAM controller on the i.MX93 and i.MX91 does not support DDR3
nor DDR4 memories.
Forbid the selection of DDR3 and DDR4 firmwares on those SoCs.
Fixes: 1ec956130d ("package/freescale-imx: Allow firmware installation on i.MX93")
Reported-by: Sebastien Szymanski <sebastien.szymanski@armadeus.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Sebastien Szymanski <sebastien.szymanski@armadeus.com>
[Julien: reword the commit log to also mention i.MX91]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since Linux 6.12, the Buildroot option BR2_LINUX_KERNEL_CUSTOM_DTS_PATH
does not work as expected on arm, arm64, mips and riscv[1]. These are
the architectures that store the in-tree DTS files in vendor-specific
subdirectories of arch/$ARCH/boot/dts/.
BR2_LINUX_KERNEL_CUSTOM_DTS_PATH was introduced in Buildroot 2012.08
(commit 69fc497df0 "Rework support for the device tree"). At the time,
the kernel kept all in-tree DTS files directly in arch/$ARCH/boot/dts/,
and this is where Buildroot drops the user's custom DTS. Vendor-specific
subdirectories appeared in Linux v3.19 for the arm64 architecture, and
this scheme was later adopted by mips, riscv and arm.
For these architectures, Linux 6.12 (commit e7e2941300d2, "kbuild: split
device tree build rules into scripts/Makefile.dtbs") made the DTB build
infrastructure incompatible with the way
BR2_LINUX_KERNEL_CUSTOM_DTS_PATH is implemented. This infrastructure now
expects all DTS files to be in vendor-specific subdirectories on the
architectures that use this scheme.
We can't update easily the current behavior of
BR2_LINUX_KERNEL_CUSTOM_DTS_PATH since it expect a list of files but
can also be used "unexpectedly" with directories [2].
BR2_LINUX_KERNEL_INTREE_DTS_NAME="st/stm32mp135f-dk-mx"
BR2_LINUX_KERNEL_CUSTOM_DTS_PATH="$(BR2_EXTERNAL_ST_PATH)/[...]/linux-dts/st"
In this case, the st directory is copied into the arch/$ARCH/boot/dts/
and BR2_LINUX_KERNEL_INTREE_DTS_NAME is used to build stm32mp135f-dk-mx dtb
as if it was intree.
Introduce BR2_LINUX_KERNEL_CUSTOM_DTS_DIR configuration
parameter to specify a list of directories that are copied as-is over
the arch/<arch>/boot/dts/ directory before building the device tree
blob:
board/acmesystems/acqua-a5/dts/
└── microchip
└── at91-sama5d3_acqua.dts
defconfig:
BR2_LINUX_KERNEL_CUSTOM_DTS_DIR="board/acmesystems/acqua-a5/dts"
Each dts file found is automatically added to the list of devicetree
to build.
BR2_LINUX_KERNEL_CUSTOM_DTS_DIR can also be used for external
devicetree overlays files:
board/ti/am574x-idk/dts/
└── ti
└── omap
└── am57xx-evm.dtso
With this new option, BR2_LINUX_KERNEL_CUSTOM_DTS_PATH is now deprecated.
Note: We want to create a list of dts files (LINUX_DTS_LIST) present in
diectrories listed by BR2_LINUX_KERNEL_CUSTOM_DTS_DIR. But
LINUX_DTS_LIST must not contain BR2_LINUX_KERNEL_CUSTOM_DTS_DIR
paths. Use GNU 'find' print format %P to print each dts file path
without their respective dts overlay directory path.
Do the same for LINUX_DTSO_LIST.
Thanks to Edgar Bonet for the initial contribution [3].
[1] https://lists.buildroot.org/pipermail/buildroot/2024-October/765463.html
[2] https://github.com/bootlin/buildroot-external-st/blob/541ba7d96330cd7da5674b46806b549a7ccf9da8/configs/st_stm32mp135f_dk_demo_defconfig#L21
[3] https://lore.kernel.org/buildroot/93f83afb-6987-441c-8e06-dab4d43b828f@grenoble.cnrs.fr/
Cc: Michael Walle <michael@walle.cc>
Cc: Gaël PORTAY <gael.portay+rtone@gmail.com>
Reported-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Edgar Bonet <bonet@grenoble.cnrs.fr>
[Romain:
- Rework the initial contribution by Edgar Bonet by
BR2_LINUX_KERNEL_CUSTOM_DTS_DIR following
Michael Walle comments and Gaël PORTAY review.
- Reword the commit log accordingly.
]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Build and install all in-tree rock5b device tree overlays.
The device tree overlays will be available in /boot, such that it is
possible for u-boot to apply one (or many) of them before booting Linux.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The linux kernel can build device tree overlays (.dtbo) itself. Add
support to build and copy them along with the actual device trees.
These can either be in-tree device tree overlays
(BR2_LINUX_KERNEL_INTREE_DTSO_NAMES) or they can be provided outside of
the kernel (BR2_LINUX_KERNEL_CUSTOM_DTS_PATH). In the latter case, the
overlay source files will be copied into the kernel tree first.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The real file is utils/generate-cyclonedx,
not utils/generate-cyclonedx.py.
Signed-off-by: Thomas Devoogdt <thomas.devoogdt@barco.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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.
Peter Korsgaard