Go forces use of the Gold linker on aarch64 due to a bug in BFD that
is fixed in Binutils >= 2.41 (that includes all versions provided by
Buildroot). Forcing Gold will break with toolchains that don't provide
it (like the Buildroot toolchains), so override the flag and use BFD.
This override should be removed if Go stops forcing Gold, and may have
to be adapted if the set of available linkers changes (e.g. with a
future Binutils update).
See: https://github.com/golang/go/issues/22040
Fixes:
http://autobuild.buildroot.org/results/a59/a59bc999e9620ff6b9d97138a2de898aadc07529
Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Reviewed-by: Yann E. MORIN <yann.morin@orange.com>
[Romain: add autobuild reference]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Currently, only the -static extldflags may be set in the
golang-package infra. However, in some cases, it might be necessary to
pass other flags, either because they are needed on a specific
architecture, or a specific C library; packages may also have a need
to pass arbitrary linker flags when they use CGO linking.
For example, on AArch64, go forcibly uses ld.gold, but it is not
available in all toolchains, and ld.bfd works nowadays (following
patch); another case is musl, where PIE is not supported with go.
Introduce FOO_EXTLDFLAGS, which we use to set those flags, and that
packages can set to pass such flags.
Migrate the current setting of -static to use that new variable.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Tested-by: Nathaniel Roach <nroach44@nroach44.id.au>
Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Reviewed-by: Yann E. MORIN <yann.morin@orange.com>
Reviewed-by: Christian Stewart <christian@aperture.us>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
There is a growing need to generate software bill of materials (SBOM) from
buildroot configurations. Right now there are different solutions available
for buildroot users `show-info`, `legal-info` and `pkg-stats`.
They all generate similar information but in a format that is specific
to buildroot.
CycloneDX is a SBOM specification that can be consumed by different services.
This patch introduces a Python script, that converts the JSON output of the
show-info Makefile target to a CycloneDX-style SBOM.
The script output contains the following information.
- A list of all packages, or "components" with information about
version, cpe (if available), applied patches.
- By default virtual packages are not listed in the SBOM.
- Additional information is added to the component 'properties' to
specify wheter the component is present on the target or the host
under the `BR_TYPE` property name.
- An overview of the licenses applicable to each package. If possible,
the names of these licenses have been matched to known SPDX license
identifiers.
- Per package, a list of (recursive) dependencies on other packages.
- A list of ignored CVE and their associated component.
More information on CycloneDX at https://cyclonedx.org/.
Usage:
make show-info | utils/generate-cyclonedx.py | jq '.'
Example output:
```
{
"bomFormat": "CycloneDX",
"$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
"specVersion": "1.6",
"components": [
{
"bom-ref": "busybox",
"type": "library",
"name": "busybox",
"version": "1.36.1",
"licenses": [
{
"license": {
"id": "GPL-2.0"
}
},
...
],
"cpe": "cpe:2.3:a:busybox:busybox:1.36.1:*:*:*:*:*:*:*",
"pedigree": {
"patches": [
{
"type": "unofficial",
"diff": {
"text": {
"content": "..."
}
}
}
]
}
"properties": [
{
"name": "BR_TYPE",
"value": "target"
}
]
},
...
],
"dependencies": [
{
"ref": "busybox",
"dependsOn": [
"host-skeleton",
"skeleton",
"skeleton-init-sysv",
"skeleton-init-common",
...
}
...
],
"vulnerabilities": [
{
"id": "CVE-2022-28391",
"analysis": {
"state": "in_triage",
"detail": "The CVE 'CVE-2022-28391' has been marked as ignored by Buildroot"
},
"affects": [
{
"ref": "busybox"
}
]
},
...
],
"metadata": {
"component": {
"bom-ref": "buildroot",
"name": "buildroot",
"type": "firmware",
"version": "2024.02-4744-gafea667f00-dirty"
}
}
}
```
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Co-authored-by: Matthias Swiggers <matthias.swiggers@mind.be>
Reviewed-by: Vincent Jardin <vjardin@free.fr>
[Arnout:
- alphabetically order imports;
- use endswith instead if 'in' to check suffix;
- add usage to help text;
- remove .py suffix.
]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
This commit adds support for listing the patches path or url applied to a
package when calling `show-info`.
To avoid making `show-info` dependant on having to download and patch the
packages there is a known limitation with the patch listing of `show-info`:
* If a package applies patches in the pre/post hook, they won't be listed
(for instance: `android-tool`, `libmad`, `gcc-initial`, `gcc-final`,
`linux-header`, ...).
* Patches defined in the `<pkg-name>_PATCH` variable will be listed as
an URL instead of listing the content with a path. For individual
patches this is probably OK, but it's not so ideal if it's a tarball
containing patches
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Co-authored-by: Matthias Swiggers <matthias.swiggers@mind.be>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
The .stamp_patched rule currently uses shell loops and conditions to
iterate over the patches in the package directory and
BR2_GLOBAL_PATCH_DIRS and to select between the versioned and
unversioned directory.
We want to add the patch list to show-info as well, so we need a way to
do this entirely in Make functions.
Introduce the function pkg-patches-dirs in pkg-utils which copies this
functionality in make syntax, and use it in the .stamp_patched rule.
As an extra simplification, only consider the version directory if
PKG_VERSION actually exists. Otherwise, we would use the directory with
a slash appended for packages without version. Why this does work, it
just looks weird for no reason.
Furthermore, introduce the function pkg-patch-hash-dirs which simply
enumerates the package directory and the package subdirectories of
BR2_GLOBAL_PATCH_DIRS. This function is used for _HASH_FILES as well.
Ideally, we should be able to factor our the handling of the version
subdirectory between the patches and hashes as well. Unfortunately, they
are treated subtly different: patches don't use the base directory if
the version directory exists, while hashes do use the base directory. We
don't want to change this behaviour.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Co-authored-by: Matthias Swiggers <matthias.swiggers@mind.be>
[Arnout:
- split into a separate patch;
- don't fully factor with _HASH_FILES because version is treaded
differently;
- introduce pkg-patch-hash-dirs;
- retain the RAWNAME comment, but move it to pkg-patch-hash-dirs;
- use foreach instead of shell loop, and $(seq) instead of exit 1;
- rewrite to retain original behaviour of only using versioned dir.
]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Add an option to install the Chelsio T6 firmware files used by the cxgb4
driver.
Signed-off-by: iliana etaoin <iliana@buttslol.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
PIDFILE was set incorrectly, watchdogd writes its PID file to
/var/run/watchdogd/pid (note the slash), which is not configurable
without patching.
Restructure the rest of the script to match current style while at it.
Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The bug could lead to incorrect "critical error" reports if that
uninitialized memory happened to contain a value that interpreted as
an int was above the critical threshold. It affected primarily scripts
running approximately one second or longer, because access happens by
timer.
Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following vulnerability:
** libgnutls: Fix potential DoS in handling certificates with numerous name
constraints, as a follow-up of CVE-2024-12133 in libtasn1. The
bundled copy of libtasn1 has also been updated to the latest 4.20.0
release to complete the fix. Reported by Bing Shi (#1553).
[GNUTLS-SA-2025-02-07, CVSS: medium] [CVE-2024-12243]
For more details, see the release announcement:
https://lists.gnupg.org/pipermail/gnutls-help/2025-February/004875.html
Update the license info for a move/rename of license files and a slight
rewording. The license clarification is now in README.md so also add that:
a8727cdb0775f5ea8073
Drop now upstreamed
0001-groups-represent-hybrid-groups-with-an-array-of-IDs.patch:
9cc9d5556d
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
With the TARGETPLATFORM fix we need to rebuild the container so move to the
latest snapshot to get updated (security) fixes.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 12e9fc1da5 ("support/docker: add tar 1.35") added logic to download
and build tar for the host, but mistyped a configure option:
configure: WARNING: unrecognized options: --disable-year2028
Fix that.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
sqlite 3.49.0 has changed its buildsystem, causing a lot of breakage
along the lines.
Although a few fixes have already been applied (and reverted in the
previous commits), there are remaining pain-points that are not trivial
to fix in a timely manner :
- the buildsystem forces an rpath to /usr/lib, and it is not obvious
how to prevent that (excepyt with patching),
- there is an optional dependency to zlib that is not accounted for,
neither in the target nor in the host variants; this causes issues
when the build host has libz-devel (or similar) already installed,
in whicxh case sqlite detets it and links with it; as it is missing
an rpath to $(HOST_DIR)/lib, this causesw a build failure when
another package pulls in zlib. See:
https://autobuild.buildroot.org/results/1a81cb7c88a41a03767a1a201ee0628468f60766/build-end.loghttps://lore.kernel.org/buildroot/20250219195112.GA2631528@pevik/T/#mb7c7ac63902ed55623a5adf5d1db4a3f60db9fef
Fixing the second issue would seem easy enough, but zlib could depend on
ccache (when that is enabled), and ccqche depends on sqlite, so that
would be a circular dependency. And there is no option in sqlite's
configure script to forcefully disable use of zlib...
A revert is the quickest solution to unbreak for the time being, as the
next release is nearing due date. Another bump can be attempted later,
that addresses all the remaining issues.
This reverts commit db85638cea.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Scott Fan <fancp2007@gmail.com>
Cc: Romain Naour <romain.naour@gmail.com>
Cc: Petr Vorel <petr.vorel@gmail.com>
Acked-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
- Bump Linux kernel to v6.12.15, update the hash file and add the
dependency on host-python3.
- Bump the FVP in the readme to version 11.27 build 19.
While at it:
- Rework the readme a bit with explicit build instructions, add a link
to the model binaries running on AArch64 host and update the model
command line to specify Arm v8.0 (as we are building for Cortex-A53).
- Turn on hashes verification and update .checkpackageignore
accordingly.
- Add myself as co-developer for this defconfig.
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
[Julien: remove "Locally calculated" in linux.hash]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Commit c619346111 (package/kodi: bump version to 21.0-Omega) added a
select onto libdisplay-info from a blind option that only represents
whether a specific subset of Kodi is available, not whether Kodi itself
is enabled.
This causes useless builds of libdisplay-info for a lot of builds where
Kodi is not enabled.
Move the select to the main Kodi symbol itself, guarded with the proper
condition, like a few existing dependencies for GBM.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Add another option for FS compression that allows fine-grained control using a
list of algorithms and optional compress-hints file. This way multiple
algorithms and pcluster sizes can be used for different files, fully exposing
EROFS compression abilities.
Signed-off-by: Jan Čermák <sairon@sairon.cz>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Add Kconfig toggles for a few more extended options that are useful for
reducing size and improving performance of EROFS images. Descriptions of the
config options were taken from the erofs-utils manpage.
Signed-off-by: Jan Čermák <sairon@sairon.cz>
[Arnout: fix Config.in help text and indentation]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Instead of having a bool option for enabling the LZ4HC compression, change the
Kconfig definition to a choice, which also adds more flexibility in the future
(e.g. for enabling ZSTD compression). The name of the old option was preserved
so defconfigs using it won't be affected.
Also both for LZMA and LZ4HC, it's now possible to define compression level.
Previously it defaulted to 9, which generates images larger than squashfs with
comparable settings (which uses level 12 by default). For LZ4HC the default if
unset would be still 9.
Use a separate config option for LZMA and LZ4HC compression level,
because their ranges and meaning are different.
Signed-off-by: Jan Čermák <sairon@sairon.cz>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
RNNoise is a noise suppression library based on a recurrent neural network.
Add an upstream post-0.2 patch to fix a build issue.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Julien: remove --disable-doc in _CONF_OPTS already in infra]
Signed-off-by: Julien Olivain <ju.o@free.fr>
This configuration builds an image for the Polyhex Debix Model A SBC
DEBIX Model A is an industrial grade single board computer
powered by NXP i.MX 8M Plus applications processor
https://www.debix.io/hardware/model-a.html
- Linux Kernel: Upstream version 6.12.14
- U-boot: Upstream version 2025.01
- ATF: Upstream version 2.12
Signed-off-by: Gilles Talis <gilles.talis@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Currently, our docker-run helper will decide on its own whether it
should use docker (preferred) or podman (fallback), as introduced in
9a629f5129 (utils/docker-run: allow running with Podman). In case
both are installed, it is not possible to exercise the podman case.
Often, 'docker' is just an alias for 'podman' when both are available,
but this is not always true - and in the latter case, the user needs to
be able to choose which one they want.
Allow the user to force the one to use, by setting the BR2_DOCKER
environment variable. If that is set and it doesn't exist, exit with
an explicit error message (rather than relying on the failure when
eventually exec-ing the specified command).
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Ricardo Martincoski <ricardo.martincoski@datacom.com.br>
Cc: Julien Olivain <ju.o@free.fr>
Cc: Fiona Klute <fiona.klute@gmx.de>
Reviewed-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
We want to redirect both stdout and stderr to the log, so just do both
redirections at once. This simplifies the call to make, which was
inherited from afdb545b28 (tools: new tool to filter the output of
make) when brmake was using unbuffer (and even then it was not entirely
waranted to do the redirection that way).
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
All our documented uses of utils/docker-run, besides running it
standalone to get an interactive shell, is to use it as a prefix
to the otherwise standard command to run, e.g.:
- ./utils/docker-run make foo_defconfig
- ./utils/docker-run make menuconfig
- ./utils/docker-run make
- ./utils/docker-run make check-package
Commit 8aad67f157 (utils/brmake: add option to run in docker) departed
from that usual convention, by hiding the call to docker-run inside
brmake, conditioned by an environment variable. The only reason is that
brmake internally used ubuffer. This is no longer the case, so we can
now use brmake together with docker-run in the usual manner.
This basically reverts commit 8aad67f157,
after resolving the conflict due to the removal of unbuffer in te
previous commit.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
When it was introduced in afdb545b28 (tools: new tool to filter the
output of make), brmake made use of unbuffer, so as to try and ensure
that no output would get lost between make printing it, and the logger
loop time-stamping it and storing it in the logfile, in case the user
would interrup the build (SIGINT, ^C)
However, unbuffer is missing in our reference build image (we could have
added it, but we missed the occasion to do so every time we updated the
reference build image).
Furthermore, the rationale for using unbuffer, although reasonable, is
not so practical: indeed, when the user hits Crtl-C, this is inherently
asynchronous, and they can't expect everything to be entirely cleanly
terminated, especially buffering. Using unbuffer is thus slightly
superfluous.
The timestamps will be slightly off because of buffering, but a build
generates so much output that this won't be a problem in practice.
Drop use of unbuffer.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Now that BR2_TOOLCHAIN_BARE_METAL_BUILDROOT_ARCH can contain multiple tuples,
BR2_TARGET_XILINX_EMBEDDEDSW can no longer be dependent on:
depends on BR2_TOOLCHAIN_BARE_METAL_BUILDROOT_ARCH = "microblazeel-xilinx-elf"
A valid definition could have "microblazeel-xilinx-elf" as just one of many
tuples in the list.
For this reason, this patch changes the dependency to:
depends on BR2_TOOLCHAIN_BARE_METAL_BUILDROOT
One side effect of this is that the user comment will be displayed now when
using multiple tuples, even if one of them is the required tuple.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Now that binutils-bare-metal, gcc-bare-metal and newlib-bare-metal packages
have been upgraded to support a list of architecture tuples, this patch
updates the toolchain-bare-metal-buildroot help text to describe the new
capability.
BR2_TOOLCHAIN_BARE_METAL_BUILDROOT_ARCH is still backwards compatible with
its prior definition as defining a single tuple with this new definition
works exactly the same as before.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Add support to gcc-bare-metal to support multiple architecture tuples
with the BR2_TOOLCHAIN_BARE_METAL_BUILDROOT_ARCH string.
To do this, custom configure, build and install commands are needed, so that
each step goes through a loop of the architecture tuples in the list.
To keep consistency with autotools, all the relevant target configurations
have been copied into the NEWLIB_BARE_METAL_CONF_OPTS while removing any
configurations that do not apply to newlib.
Also, the following configs were not taken because newlib is being built for
each of the bare-metal targets and not the main target of Buildroot.
$$(TARGET_CONFIGURE_OPTS)
$$(TARGET_CONFIGURE_ARGS)
--target=$$(GNU_TARGET_NAME)
--host=$$(GNU_TARGET_NAME)
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
