board/freescale: fix arm-trusted-firmware for binutils 2.39+
The NXP arm-trusted-firmware forks use an older version of ATF that will
error with "LOAD segment with RWX permissions". Similar patches are
present in boot/arm-trusted-firmware/ for older ATF versions.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/5134910852
https://gitlab.com/buildroot.org/buildroot/-/jobs/5134910630
https://gitlab.com/buildroot.org/buildroot/-/jobs/5134910631
(and a bunch of others which are not yet visible as they are hidden
by other build issues)
LICENSE: update copyright years & switch to Perl Artistic
see https://metacpan.org/release/TIMLEGGE/Convert-ASN1-0.34/diff/TIMLEGGE/Convert-ASN1-0.33#LICENSE
Uacme hardcodes the mbedtls linker flags / mbedtls does not provide a .pc
file, so we need to manually also link with zlib if mbedtls is built with
compression support.
Thomas Petazzoni [Sat, 30 Sep 2023 09:21:47 +0000 (11:21 +0200)]
docs/website/association.html: move buildroot-association to Gitlab
The buildroot-association repository used to be hosted on Github, then
was closed for some banking issues. We're now making it public again,
but on Gitlab like the rest of Buildroot.
Thomas Petazzoni [Sat, 30 Sep 2023 08:25:05 +0000 (10:25 +0200)]
docs/website: simplify section on Git repo
Now that the snapshot tarball section is gone, the "Source code" block
has only one sub-block "Repository" which makes it look odd. So bring
the sub-block content into the parent block, and rename this parent
block "Git repository".
As this requires re-indenting the whole HTML soup, take advantage of
this to use <p>...</p> in a more correct manner.
Thomas Petazzoni [Sat, 30 Sep 2023 08:25:03 +0000 (10:25 +0200)]
docs/website: move Git repository to Gitlab
We're now using Gitlab as our official Git repository, so let's update
the website accordingly. Gitlab only provides https:// access, so drop
the explanation about the Git native protocol being more efficient
than HTTP (also because that's no longer true).
Commit 32cec3be976 (docs/manual: rename *.txt as *.adoc) renamed the manual
files but forgot to update the reference in the DEVELOPERS file, causing
check-package to warn:
WARNING: 'docs/manual/adding-packages-meson.txt' doesn't match any file, line 851
Thomas Petazzoni [Sat, 30 Sep 2023 07:54:23 +0000 (09:54 +0200)]
package/gcc: add license information
This commit adds the licensing information for the host-gcc-initial,
host-gcc-final and gcc-final packages.
For host-gcc-initial and host-gcc-final, instead of duplicating the
information, we use common variables coming from gcc.mk.
Of course for the target gcc-final, we use a different license than
for host-gcc-final, as it's the whole point of this series: be able to
describe that the target side of gcc is GPL-3.0 with linking
exception.
Thomas Petazzoni [Sat, 30 Sep 2023 07:54:22 +0000 (09:54 +0200)]
package/gcc/gcc-final: add a target variant in charge of target installation
This commit adds a target package "gcc-final", which is a target
package responsible for installing the gcc runtime libraries to
STAGING_DIR and TARGET_DIR. This task was so far done by the host
gcc-final package.
The motivation for splitting it up into a target package is to be able
to properly handle the licensing situation of GCC, where the host part
of GCC (the compiler itself) is under GPLv3, but the runtime libraries
on the target are under GPLv3-with-exception. So far, we were not
handling at all the license of gcc.
So what this commit does is:
* Add a gcc-final target package, which is depended on by the
toolchain-buildroot package, and which depends on
host-gcc-final.
* Moves to gcc-final the logic for installing target/staging
libraries
Thomas Petazzoni [Sat, 30 Sep 2023 07:54:21 +0000 (09:54 +0200)]
package/gcc/gcc-final: move hook further down
The HOST_GCC_FINAL_M68K_LIBGCC_FIXUP hook is tweaking the staging
directory. In preparation for additional rework, let's move it further
down in the file so that the diff of the rework will be easier to look
at.
Thomas Petazzoni [Sat, 30 Sep 2023 07:54:20 +0000 (09:54 +0200)]
package/gcc/gcc-final: split lib install by target/staging
Right now the library installation was split between installation of
static libs vs. shared libs. In preparation for additional rework, it
makes more sense to split it between target installation and staging
installation.
For staging installation we simply install $(lib)* so that both static
and shared libraries are copied.
For target installation, we only install when shared libraries are
used, and we copy $(lib).so*
Thomas Petazzoni [Sat, 30 Sep 2023 07:54:19 +0000 (09:54 +0200)]
package/gcc/gcc-final: move to make foreach loops
This provides better error handling, and is more in line with our
current coding style. We also replace ";" by "&&" for the same reason
of proper error handling.
Thomas Petazzoni [Sat, 30 Sep 2023 07:54:17 +0000 (09:54 +0200)]
package/gcc/gcc-final: rework installation of libgcc_s/libatomic
The installation of libgcc_s/libatomic (which have to go in /lib) is
handled differently than all the other libraries (which go in
/usr/lib). For consistency, and in preparation for additional changes
in this area, handle both in a more consistent manner, with a new
HOST_GCC_FINAL_LIBS that looks like HOST_GCC_FINAL_USR_LIBS.
Consequently, the hook HOST_GCC_FINAL_INSTALL_USR_LIBS is renamed to
HOST_GCC_FINAL_INSTALL_LIBS, and made unconditional rather than being
conditional on ifneq ($(HOST_GCC_FINAL_USR_LIBS),). Indeed, we now
need to install libraries in /lib unconditionally, and if
HOST_GCC_FINAL_USR_LIBS is empty, the loops will simply not iterate on
any element, and they will not install anything in /usr/lib.
pam_access.c: In function 'pam_sm_authenticate':
pam_access.c:1084:13: error: 'for' loop initial declarations are only allowed in C99 mode
for (int i = 0; filename_list[i] != NULL; i++) {
^
Those build failures could be fixed by adding -std=c99 but then the
build will fails because stdadtomic.h is mandatory since
https://github.com/linux-pam/linux-pam/commit/a35e092e24ee7632346a0e1b4a203c04d4cd2c62
With bump of package/e2fsprogs to 1.47.0 [1] a freshly generated
ext4 fs has unfortunately different default features enabled
(e.g. metadata_csum_seed). This and some other newer fs features
(e.g. large_dir) are however not supported by our grub2.
Thus, newly generated ext-based rootfs won't be recognized by grub2
and are therefore not bootable/usable from grub2 anymore. This is
an issue already known to other Linux derivates [2],[3],[4].
This commit introduces two additional upstream patches to
package/grub2 which adds EXT4_FEATURE_INCOMPAT_CSUM_SEED and
EXT4_FEATURE_INCOMPAT_LARGEDIR to the EXT2_DRIVER_IGNORED_INCOMPAT
list of ignored incompatible ext features, allowing grub2 to
use ext filesystems with these newer default feature sets.
Older Batman-adv versions fail to build with kernel 6.4.x
with following error message:
bat_iv_ogm.c:283:18: error: implicit declaration of function 'prandom_u32_max'; did you mean 'prandom_u32_state'? [-Werror=implicit-function-declaration]
The weston runtime test uses the CRC of the framebuffer to detect that
"something" is being drawned on the framebuffer. This requires that the
sampling of the CRC happens does not happen too early after trigerring
an action, or the rendering may be not be finishe, either:
- weston may not have had time to initialise, or
- the test application may not have started rednering,
The sequence of rendering that has been observed yields this sequence of
CRCs (elided for brevity):
- boot:
- alternating between 0x4c4126bf and 0x5d2f9aa5: console cursor
blinking
- start weston:
- 0x4c4126bf: weston switches to a cleared vt, no blinking cursor
...
- 0xe54b7895: weston is starting
...
- 0xe54b7895: wayland socket appears!
...
- 0x6bf28bdf: weston is ready
...
- start weston-simple-egl:
- 0x6bf28bdf: application is starting
...
- 0xNNNNNNNN: random CRCs while the application renders
...
- stop weston-simple-egl:
- 0xNNNNNNNN: zero, one, or two random CRCs while the application
renders before it handles SIGTERM
- 0x6bf28bdf: application is stopped
...
- stop weston:
- 0x6bf28bdf: a few CRC identical to when weston was started, while
weston is processing SIGTERM
- oscillating between 0x4c4126bf and 0x5d2f9aa5: console cursor
blinking, back to initial vt, weston dead.
So, we need to wait "enough" after each action. Moreover, when the
wayland socket appears, weston may not have stabilised yet, so we also
need to wait after the socket appears.
Ben Dooks [Wed, 27 Sep 2023 08:58:23 +0000 (09:58 +0100)]
board/qemu/aarch64-virt/linux.config: enable base ACPI support
When testing the virt machine with EDK2, the buildroot 6.1 kernel
will not boot as it has no base ACPI support. Whilst you can run
qemu with the -no-acpi option, it would help if basic ACPI support
was there as otherwise there is no output from the kernel post the
ACPI BIOS initialisation.
pkg-config --variable=version luajit returns 2.1.1693350652 since bump of
luajit in commit c9dcd9e459d6e0a955129ab42916d4c1140bdc3d, but the directory
is still host/share/luajit-2.1 - resulting in the following build failure:
luajitluajit:: unknown luaJIT command or jit.* modules not installedunknown luaJIT command or jit.* modules not installed
package/go: cgo for the target needs the toolchain
Building go with cgo support needs to build some .c files to generate target
support code, and thus calls the cross C compiler, which is failing when the
toolchain is not built before host-go:
>>> host-go 1.21.1 Building
cd .../build/host-go-1.21.1/src && GO111MODULE=off GOCACHE=.../per-package/host-go/host/share/host-go-cache GOROOT_BOOTSTRAP=.../per-package/host-go/host/lib/go-1.19.11 GOROOT_FINAL=.../per-package/host-go/host/lib/go GOROOT=".../build/host-go-1.21.1" GOBIN=".../build/host-go-1.21.1/bin" GOOS=linux CC=/usr/bin/gcc CXX=/usr/bin/g++ CGO_ENABLED=1 CC_FOR_TARGET=".../per-package/host-go/host/bin/arm-linux-gcc" CXX_FOR_TARGET=".../per-package/host-go/host/bin/arm-linux-g++" GOOS="linux" GOARCH=arm GOARM=6 GO_ASSUME_CROSSCOMPILING=1 ./make.bash
Building Go cmd/dist using .../per-package/host-go/host/lib/go-1.19.11. (go1.19.11 linux/amd64)
go tool dist: cannot invoke C compiler [".../per-package/host-go/host/bin/arm-linux-gcc"]: fork/exec .../per-package/host-go/host/bin/arm-linux-gcc: no such file or directory
Go needs a system C compiler for use with cgo.
To set a C compiler, set CC=the-compiler.
To disable cgo, set CGO_ENABLED=0.
This happens systematically with PPD, and happens without PPD when
host-go is explicitly built (by running: "make host-go").
Since only CGO support needs to compile C files, only add the toolchain
dependency in that case.
When the target is not supported by go, then there is obviously no need
to depend on the toolchain (even if we unconditionally enable cgo
support in only-for-the-host host-go).
Adam Duskett [Tue, 19 Sep 2023 20:42:51 +0000 (14:42 -0600)]
package/flutter-gallery: new package
Flutter Gallery is a resource to help developers evaluate and use Flutter.
It is a collection of Material Design & Cupertino widgets, behaviors, and
vignettes implemented with Flutter.
Adam Duskett [Tue, 19 Sep 2023 20:42:50 +0000 (14:42 -0600)]
package/flutter-pi: new package
flutter-pi is one of many flutter-embedders. However, flutter-pi is unique
because it doesn't require X or Wayland to run. So long as there is support for
KMS and DRI flutter-pi should run on any platform that flutter-engine supports.
Adam Duskett [Tue, 19 Sep 2023 20:42:49 +0000 (14:42 -0600)]
package/flutter-engine: new package
There are many issues with this package:
- The release tarballs from https://github.com/flutter/engine are in no state
to compile. They are only for the use of gclient to download a source
directory structure suitable to build the Flutter engine! If you download,
extract and attempt to run `./tools/gn --no-goma --no-prebuilt-dart-sdk`, you
receive the error message:
`No such file or directory: 'flutter/flutter/third_party/gn/gn.'
But wait! Wasn't the gn binary just called? No, that's a wrapper in the
Flutter source tree that formats arguments to call the real gn binary.
The real gn is not provided in the tarball but is downloaded via gclient
(among many other supporting repositories.)
Even worse, the flutter buildsystem depends on the .git dirs being present.
(https://github.com/meta-flutter/meta-flutter/issues/271) This dependency
means it is not possible to create a reproducible tarball from the downloaded
sources, which is why there is no .hash file provided.
I have asked the flutter project to release full tarballs suitable for
compiling here: https://github.com/flutter/flutter/issues/130734
- Flutter engine includes a patched copy of clang that must be used to compile.
Using a Buildroot-build clang results in linking warning and errors.
As such, we depend on LLVM_ARCH_SUPPORTS but use the included clang for
building. On the plus side, this saves time having to compile clang.
- flutter-engine relies on the "PUB_CACHE", that is provided by flutter-sdk,
so we need a build dependency, even if no tool from host-flutter-sdk-bin
is used to build flutter-engine
Tested with:
- Debian 11 and 12
- Ubuntu 18.04, 20.04, and 22.04
- Fedora 38
- Per-package directories
Signed-off-by: Adam Duskett <[email protected]>
[[email protected]:
- search gclient.py from PATH
- indent shell script with 4 spaces
- reorganise schell script with prepare/cleanup
- tweak comment about weirdness of flutter buildsystem
- use suitable-extactor and TAR_OPTIONS
- use FLUTTER_SDK_BIN_PUB_CACHE
- add dependency to host-futter-sdk-bin (Adam)
] Signed-off-by: Yann E. MORIN <[email protected]>
Adam Duskett [Tue, 19 Sep 2023 20:42:47 +0000 (14:42 -0600)]
package/depot-tools: new package
Chromium and Chromium OS use a package of scripts called
depot_tools to manage checkouts and code reviews. This package
also includes the gclient utility.
gclient is a Python script to manage a workspace of modular dependencies that
are each checked out independently from different subversion or git
repositories. Features include:
- Dependencies can be specified on a per-OS basis.
- Dependencies can be specified relative to their parent dependency.
- Variables can be used to abstract concepts.
- Hooks can be specified to be run after a checkout.
- .gclient and DEPS are Python scripts. You can hack in easily or add
additional configuration data.
.gclient file: It's the primary file. It is, in fact, a Python script. It
specifies the following variables:
- solutions: an array of dictionaries specifying the projects that will be
fetched.
- hooks: additional hooks to be run when this meta checkout is synced.
- target_os: an optional array of (target) operating systems to fetch
OS-specific dependencies for.
- cache_dir: Primarily for bots, multiple working sets use a single git
cache.
gclient is necessary for checking out the flutter-engine source code, as the
release tarballs provided on the flutter-engine github are in no state to
compile. Google expects the use of gclient to download a source directory
structure suitable to build the Flutter engine.
Removed all patches, they are now included in this release.
Added other patches fixing errors.
Removed option BR2_PACKAGE_PPPD_RADIUS, upstream build system, now auto-
conf-based, does not support disabling the radius plugin.
Removed BR2_PACKAGE_PPPD_OVERWRITE_RESOLV_CONF, upstream now defaults to
/etc, quoting README:
"Note that if you have built and installed previous versions of this
package and you want to continue having configuration and TDB files in
/etc/ppp, you will need to use the --sysconfdir option to ./configure."
Switched build system to autoconf, added optional systemd support.
Added configure option to enable multilink support which now defaults to
false but was enabled before:
https://github.com/ppp-project/ppp/blob/2.4.9/pppd/Makefile.linux#L57
James Hilliard [Sun, 7 Aug 2022 00:38:30 +0000 (18:38 -0600)]
package/python-cryptography: migrate to setuptools-rust infrastructure
We can now significantly simplify the python-cryptography build using
the new setuptools-rust setup type introduced in the python package
infrastructure.
James Hilliard [Sun, 7 Aug 2022 00:38:28 +0000 (18:38 -0600)]
package/pkg-python: add setuptools-rust and maturin infrastructure
Python has two build backends for packages that use Rust:
setuptools-rust and maturin. Both are provided by the pyo3 package
infrastructure (but that's not relevant for Buildroot).
The setuptools-rust build backend is a setuptools extension that is
capable of building python rust extensions.
The maturin build backend is a pep517 build extension that is itself
written in rust, it is itself bootstrapped using setuptools-rust but
is not itself a setuptools extension.
Both are from the pyo3 build infrastructure, so we add both of them in a
single patch. They also share a lot of the cargo-specific handling.
Signed-off-by: James Hilliard <[email protected]>
[Arnout: remove the _PYO3_ENV variables, the add little benefit] Signed-off-by: Arnout Vandecappelle <[email protected]>
package/localedef: build issue with old glibc (<= 2.38)
While building host-localedef from glibc 2.38 sources, it uses the
features.h header from its sources that define _ISOC2X_SOURCE 1 as
soon as _GNU_SOURCE is defined.
_ISOC2X_SOURCE enable __GLIBC_USE_ISOC2X 1 that enable the header
redirection to use __isoc23_* functions introduced in glibc 2.38 [1].
If an older version is installed on the host, those functions
doesn't exist and break the build.
Add a local patch to keep _ISOC2X_SOURCE and __GLIBC_USE_ISOC2X
disabled.
Enable mathvec explicitly on aarch64(be) since it's now enabled by
default [1]. aarch64 mathvec requires at gcc-10 but Buildroot already
provide gcc-11 as minimum version.
Don't use --enable-fortify-source for now in order to keep original
behavior while doing the glibc version bump (and because some
architecture doesn't support well fortify-source, i.e Microblaze).
Postpone this change to a follow up commit.
Keep the "deprecated" libcrypt enabled just in case if some
application are not yet ready to use an alternative such as libxcrypt.
Security related changes:
CVE-2023-25139: When the printf family of functions is called with a
format specifier that uses an <apostrophe> (enable grouping) and a
minimum width specifier, the resulting output could be larger than
reasonably expected by a caller that computed a tight bound on the
buffer size. The resulting larger than expected output could result
in a buffer overflow in the printf family of functions.
Runtime tested with Qemu on Gitlab-ci:
https://gitlab.com/kubu93/buildroot/-/pipelines/998435203
https://gitlab.com/buildroot.org/toolchains-builder/-/pipelines/998926028
- Switch to cmake-package as autotools has been removed since version
9.0.0
- This bump will fix the following build failure with gcc 13 thanks to
https://github.com/OSGeo/PROJ/pull/3459/commits/b0b8937c56ced8eb0ffef532b9c691a1a5fc8634:
In file included from proj_json_streaming_writer.cpp:34:
proj_json_streaming_writer.hpp:42:14: error: 'int64_t' in namespace 'std' does not name a type
42 | typedef std::int64_t GIntBig;
| ^~~~~~~
package/libvpx: Add upstream security patch to fix CVE-2023-5217
Fixes CVE_2023-5217: Heap buffer overflow in vp8 encoding in libvpx in
Google Chrome prior to 117.0.5938.132 and libvpx 1.13.1 allowed a remote
attacker to potentially exploit heap corruption via a crafted HTML page.
Small improvements to on-screen use only. CLI -B and GUI 'B' to toggle
boxes around stats. CLI -^ and '^' to change units for Disk I/O KB/s ->
MB/s -> GB/s. This happen temporarily too if the size of the statistic
will not fit on-scree. Code changed to ensure clean compile for GCC 12
which does extra checks but got confused by some perfectly good C code!
Note: updated makefile makefile
/home/buildroot/autobuild/run/instance-2/output-1/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-buildroot-linux-gnu/12.3.0/../../../../mipsel-buildroot-linux-gnu/bin/ld: stress-crypt.o: in function `$L17':
stress-crypt.c:(.text+0x2dc): undefined reference to `crypt_r'
projects / buildroot-mgba.git / log