Do not set -march=rv64gcv1p0 when building for riscv32 to fix the
following build failure raised since bump to version 1.0.7 in commit
0db3c08daf and
7c15872e81:
cc1plus: error: ABI requires '-march=rv32'
Fixes:
- http://autobuild.buildroot.org/results/3f8def50c93f73c26339f72d6a13951d5fb41c30
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Commit 0db3c08daf "package/highway: bump to version 1.0.7" updated the
package, but forgot to update the legal information accordingly.
Highway was relicensed from "Apache-2.0" (only) to dual "Apache-2.0 or
BSD-3-Clause" in upstream commit [1]. This commit was first included
in Highway version 1.0.6. See [2].
This commit updates _LICENSE, _LICENSE_FILES and adds the new license
hash.
[1] 92a7139f88
[2] https://github.com/google/highway/releases/tag/1.0.6
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
libffi is optional, not mandatory since bump to version 1.22.0 in commit
1e12b7dd49 and
89b3207376
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The MICROPYTHON_MAKE_ENV variable contained two things;
- the comon target environment variables CC, CFLAGS et al. defined in
TARGET_MAKE_ENV,
- the GIT_DIR workaround
Commit 9024e18665 (package/micropython: drop GIT_DIR=. workaround)
totally dropped the assignment to MICROPYTHON_MAKE_ENV, but did not
replace its expansin with TARGET_MAKE_ENV.
This yields build error like:
LINK build-standard/micropython
arm-linux-gcc: ERROR: unsafe header/library path used in cross-compilation: '-L/usr/lib64/../lib64'
Fix this by expanding TARGET_MAKE_ENV in lieu of MICROPYTHON_MAKE_ENV.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
See release notes (https://github.com/redis/redis/blob/7.2.4/00-RELEASENOTES):
================================================================================
Redis 7.2.4 Released Tue 09 Jan 2024 10:45:52 IST
================================================================================
Upgrade urgency SECURITY: See security fixes below.
Security fixes
==============
* (CVE-2023-41056) In some cases, Redis may incorrectly handle resizing of memory
buffers which can result in incorrect accounting of buffer sizes and lead to
heap overflow and potential remote code execution.
Bug fixes
=========
* Fix crashes of cluster commands clusters with mixed versions of 7.0 and 7.2 (#12805, #12832)
* Fix slot ownership not being properly handled when deleting a slot from a node (#12564)
* Fix atomicity issues with the RedisModuleEvent_Key module API event (#12733)
Signed-off-by: Titouan Christophe <titouanchristophe@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since commit 2a8065e "package/postgresql: bump version to 16.1", the
postgresql service fail to start at runtime with an error:
FATAL: could not load library "/usr/lib/postgresql/dict_snowball.so": /usr/lib/postgresql/dict_snowball.so: undefined symbol: CurrentMemoryContext
This is due to the Posgresql autotool configure script trying to
detect whether the toolchain linker needs --export-dynamic or not.
This test is done with a runtime execution of a test program, and
therefore cannot run in cross-compilation. In that case, the
configure script assumes it is not needed. See commit [1], included
in PostgreSQL v16.0.
This commit fixes the issue by forcing the value in _CONF_ENV, as
suggested in an upstream bug report [2]. The package has already a
Kconfig dependency on !BR2_STATIC_LIBS, so the value can be
unconditionally set.
Note that upstream is not considering cross-compiling as supported, and
are not keen on fixing any cross-compiling issue [3].
[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=9db49fc5bfdc0126be03f4b8986013e59d93b91d
[2] https://www.postgresql.org/message-id/79e63515-0f5e-30f4-136d-96e23b1a817d%40posteo.de
[3] https://www.postgresql.org/message-id/1266022.1701958693%40sss.pgh.pa.us
Signed-off-by: Julien Olivain <ju.o@free.fr>
Reviewed-by: Maxim Kochetkov <fido_max@inbox.ru>
[yann.morin.1998@free.fr: add upstream ML thread on the issue]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Set WARNINGS="" to disable -Werror and fix the following build failure
raised since bump to version 1.2.17 in commit
53779570e5 and
b8d9634a1a:
event.c: In function 'zlog_event_new':
event.c:94:72: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
94 | a_event->tid_hex_str_len = sprintf(a_event->tid_hex_str, "%x", (unsigned int)a_event->tid);
| ^
cc1: all warnings being treated as errors
Fixes:
- http://autobuild.buildroot.org/results/21e9212dbb3d77108b45f755890a8e66b23d2407
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Flutter-engine is by name an engine, i.e. a runtime for applications, a
super-library of sorts. As such, it makes more sense for applications to
select flutter-engine rather than to depend on it.
Change flutter-pi to select flutter-engine.
It also brings flutter-pi on par with ivi-homescreen, another embedder.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[yann.morin.1998@free.fr: reword commit log]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Remove and create the kernel_blob.bin file in the flutter_assets directory:
When Flutter compiles the source code, it creates the kernel_blob.bin file,
a Dart Kernel Bytecode of the application.
If kernel_blob.bin exists inside the flutter_assets directory, then the
application source code can be extracted with nothing more than apktool.
Not only is this a security risk, it's also redundant and a waste of space.
Removing the kernel_blob.bin file generated for flutter-gallery saves 86M!
Because this package is a reference package, and some applications may check
if the kernel_blob.bin file exists, we also touch a blank kernel_blob.bin
file.
Do not use relative symlinks:
Users may install their applications in any arbitaryt location, not
necessarily in the /usr/share/flutter/${package_name} directory. Because
flutter-gallery is a reference application, using exact symlinks to
icudtl.dat and libflutter_engine.so is preferable.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
As the flutter-gallery package is a reference package for users wishing to use
Flutter for their UX with Buildroot, this package must have the correct build
options. Indeed, this package currently starts and runs, but only because of
the 0001-remove-GetStorage.patch. Through testing, flutter-gallery fails to
run during the following scenario:
- The xdg-user-dirs package is ported and present.
- flutter-gallery depends on xdg-user-dirs.
- The 0001-remove-GetStorage.patch file is removed.
After extensive testing and comparing the current build arguments against what
the meta-flutter repository for Yocto passes to all of the applications that
inherit flutter-app, it is clear that handling the dart_plugin_registrant.dart
file is missing from the dart arguments in the flutter-gallery build step.
As the documentation for the dart_plugin_registrant.dart file is nonexistent
in any official documentation. However, there is a comment from an issue on
the official dart-lang/sdk page on Github that explains what this file is
(and refers to the Dark SDK source code instead of official documentation.)
From https://github.com/dart-lang/sdk/issues/52506#issuecomment-1562806787:
```
The dart_plugin_registrant.dart is a very special file. It's neither included
in the Dart app nor any dependent packages. Rather it's an artificially
created file by the flutter tools. It contains logic to run plugin
registration logic.
A flutter build will eventually compile the Dart application where it will add
<dir>/.dart_tool/flutter_build/dart_plugin_registrant.dart as an extra source
file (see here). Additionally it will also inject that uri as a constant into
Dart source code via a -Dflutter.dart_plugin_registrant=<uri>.
Once the app runs it will access the
package:flutter/src/dart_plugin_registrant.dart:dartPluginRegistrantLibrary
constant and use it to look up the library object and then invoke the plugin
registration logic.
```
Now that what the dart_plugin_registrant.dart does is understood, we need to
pass the following to the dart binary during the flutter-gallery build step:
-Dflutter.dart_plugin_registrant=file://[...]/dart_plugin_registrant.dart:
Injects a file containing the logic to run the plugin registration logic as
a constant into the flutter-application source code.
--source file://$(@D)/.dart_tool/flutter_build/dart_plugin_registrant.dart:
Adds the dart_plugin_registrant.dart file as a source file to compile.
--source package:flutter/src/dart_plugin_registrant.dart:
Binds the plugin implementation to the platform interface based on the
configuration of the app's pubpec.yaml, and the plugin's pubspec.yaml.
The native_assets.yaml file provides the native-assets mapping for
@Native external functions. The flutter-gallery package has no functions
marked as @Native; however, calling "flutter build bundle" creates a blank
template "native_assets.yaml" file, which is safe to include in the build.
This line, while not necessary for flutter-gallery, may be helpful for other
users who use @Native external functions in their applications, and this
example makes porting other applications quicker and easier.
Finally, there is a known issue when using the dart_plugin_registrant.dart
file outlined here: https://github.com/flutter/flutter/issues/137972.
To summarize: If a user fails to pass the --obfuscate flag to gen_snapshsot
when using the dart_plugin_registrant.dart file, their application may fail
to start. One such application is Gallery, which I have independently verified.
As such, pass the --obfuscate flag to gen_snapshot to ensure that
flutter-gallery properly starts when building with the additional
dart_plugin_registrant.dart arguments above.
However, I acknowledge that the obfuscate flag hides function and class names
in compiled Dart code, and there are some cases when a user should avoid using
the flag. For example, when using the runtimeType API:
https://api.flutter.dev/flutter/dart-core/Object/runtimeType.html. However,
this is not the case with flutter-gallery, and the --obfuscate flag is needed.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[yann.morin.1998@free.fr: restore FLUTTER_RUNTIME_MODES]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
To make the next patch easier to understand, add a configure step to the
flutter-gallery.mk file. The `$(HOST_FLUTTER_SDK_BIN_FLUTTER) build bundle`
command is placed in the configure step because it generates several files
needed for the flutter_gen_snapshot tool to generate the target .so file.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The canonical name for the 'pub' action is 'pub', while 'packages' is
just an alias. Switch to using the canonical name.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[yann.morin.1998@free.fr: split off to its own commit]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
As Yann mentioned in commit 9d8497e79d, a
dependency on a glibc toolchain implies a dependency on
BR2_TOOLCHAIN_HAS_THREADS_NPTL. As such, remove the dependency from
package/flutter-engine/Config.in.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The current depot-tools version is from Jul 13 2023, and there is a bug
where when building with PPD enabled, building a Flutter application on
my laptop running Fedora 39 or even in the Debian 11 container fails due
to permission issues when running rsync such as:
/usr/bin/sed: couldn't open temporary file [...]/output/per-package/flutter-gallery/host/share/flutter/sdk/.vpython-root/0e1e32/lib/python3.8/sed763MrF: Permission denied
make: *** [package/pkg-generic.mk:267: [...]/output/build/flutter-gallery-2.10.2/.stamp_configured] Error 123
After several hours of attempting to find the exact cause of the issue
by parsing git logs of the depot_tools repository and cross-referencing
bugs on https://bugs.chromium.org/p/chromium/issues I am unable to
determine the exact reason why the problem occurs or the exact commit
that fixes the issue.
However, updating depot-tools does indeed fix the issue, and looking at
the source code between 4e87f5bf and 8d14454b shows improvements to
several bash scripts, such as gclient, vpython3, and spid. All of which
could be culprits of this bug. As flutter-engine is the only package
that uses host-depot-tools, it is safe to update.
This permission bug is present on PPD and normal builds, but causes a
build to crash only on PPD because of rsyncing. On non-ppd builds, the
bug only causes some minor annoyance when trying to run `make clean`
because permission denials crop up when trying to remove the
.vpython-root directory.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[yann.morin.1998@free.fr:
- copy the cover-letter description as commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The keyboard manager plugin is also missing the flutter/standard_method_codec.h
header.
- Add shell/plugins/keyboard_manager/keyboard_manager.h to the patch.
- Rename the patch to
0001-add-missing-headers-to-the-audio-players-and-keyboar.patch
Upstream pull request updated as well.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
When running the command "flutter pub get," the plugins are stored in the
pub-cache directory along with their sha256sum hashes. The default location of
the pub-cache directory is current $(HOST_DIR)/share/flutter/sdk/.pub-cache,
which is not an acceptable choice by default because every plugin is
re-downloaded during every build of a flutter application either during a new
build or when building with the per-package-directory option enabled.
Furthermore, keeping the pub-cache in its current location prevents users from
committing the pub-cache directory to git for faster rebuilds of a
Buildroot-based system, as users cannot store the pub-cache for later use.
To fix the above issue completely, the following two changes must occur:
- Change the hard-coded Flutter pub-cache location to
$(DL_DIR)/br-flutter-pub-cache.
- Remove the `rm -rf $(HOST_FLUTTER_SDK_BIN_SDK)/.pub-cache` and the
associated comment about why the build system removes the .pub-cache
directory. After further research, the help text of the precache command
reads, "Populate the Flutter tool's cache of binary artifacts."
The current reasoning listed in the comments is not accurate for a
the following reasons:
1. We do not want to remove their directory if users already have a pub
cache they have symlinked to.
2. If the flutter-sdk-bin package previously set up the pub-cache, then
the pub-cache directory is set up with the options we want, and there
is no reason to remove the pub-cache directory.
Note that upstream considers it safe to have multiple instances of
readers/writers to the pub cache concurently, which is a situation that
can happen when two flutter-based pacakges are going to be built in
parallel. There have been reports upstream [0] [1] [2] where concurrency
was an issue, and they have always been fixed [3] [4] (or considered
fixed already). So we can assune that, if the conncurrent ccess to the
shared pub-cache causes issues, that will be an upstream bug that will
get solved.
If that turns out to be an unsolvable problem, we'll still have the
option to run the pub-get commands under flock.
[0] https://github.com/dart-lang/pub/issues/1178
[1] https://github.com/dart-lang/pub/issues/3404
[2] https://github.com/dart-lang/pub/issues/3420
[3] https://github.com/dart-lang/pub/issues/1178#issuecomment-1006489414
[4] https://github.com/dart-lang/pub/issues/1178#issuecomment-1007273739
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[yann.morin.1998@free.fr: add blurb about concurrent access]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The BCM2712 of the RaspberryPi 5 supports for 16KB page size.
This adds support for 16 KB on ARM64.
Signed-off-by: Gaël PORTAY <gael.portay@rtone.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Update LICENSE.txt hash for a change in copyright year for 2024.
Signed-off-by: Peter Macleod Thompson <peter.macleod.thompson@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Buildroot commit c50e9c21f0 initially
added the package onevpl (meanwhile renamed to libvpl) and forgot to
add all dependencies of BR2_PACKAGE_LIBDRM_INTEL.
Fixes:
http://autobuild.buildroot.org/results/8fa/8fa0f2cd7a027d3d8fae56125621b0b814e132da/
Note: BR2_PACKAGE_LIBDRM_HAS_ATOMIC is always true on x86, but it is
propagated for consistency with the actual dependencies of libdrm-intel.
Notes: this means the current comntition in the .mk is correct in
practice, even if it does not account for the atomic case on x86.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
[yann.morin.1998@free.fr: add notes]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit df57de12f9)
[Peter: drop Makefile/Vagrantfile changes]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 8526e60a1f)
[Peter: drop Makefile change]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 1567fbd72d didn't fully fix the
wolfssl build failure because the include on wolfssl/options.h was still
missing:
/home/autobuild/autobuild/instance-6/output-1/build/libuwsc-3.3.5/src/ssl.c:62:5: error: unknown type name 'SSL_CTX'
62 | SSL_CTX *ctx;
| ^~~~~~~
While at it, add upstream tag to patches
Fixes:
- http://autobuild.buildroot.org/results/edc49cce5b1f456d980841f4c315e7cd784b1561
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As found out by Yann E. Morin in [1], apcupsd configure script is ugly,
and uses gcc to do the link line-wrapping which will raise the following
build failure with gcc 13:
/home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64le-buildroot-linux-gnu/13.2.0/../../../../powerpc64le-buildroot-linux-gnu/bin/ld: /home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64le-buildroot-linux-gnu/13.2.0/../../../../powerpc64le-buildroot-linux-gnu/lib/../lib64/libsupc++.a(eh_alloc.o): in function `std::basic_string_view<char, std::char_traits<char> >::compare(unsigned long, unsigned long, char const*, unsigned long) const':
eh_alloc.cc:(.text._ZNKSt17basic_string_viewIcSt11char_traitsIcEE7compareEmmPKcm[_ZNKSt17basic_string_viewIcSt11char_traitsIcEE7compareEmmPKcm]+0x44): undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)'
It will also raise the following build failure on sparc/arc:
/home/autobuild/autobuild/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arceb-snps-linux-uclibc/9.2.1/../../../../arceb-snps-linux-uclibc/bin/ld: /home/autobuild/autobuild/instance-3/output-1/host/arceb-buildroot-linux-uclibc/sysroot/lib/libsupc++.a(eh_throw.o): in function `__exchange_and_add_dispatch':
/SCRATCH/arcjenkins2/slaves/ru20-custom-arcgnu2/workspace/arcoss_verification/arc_gnu_toolchain_release/arc_gnu_toolchain_release/bd-uclibceb/gcc-stage2/arceb-snps-linux-uclibc/libstdc++-v3/include/ext/atomicity.h:82: undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)'
/home/autobuild/autobuild/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arceb-snps-linux-uclibc/9.2.1/../../../../arceb-snps-linux-uclibc/bin/ld: /SCRATCH/arcjenkins2/slaves/ru20-custom-arcgnu2/workspace/arcoss_verification/arc_gnu_toolchain_release/arc_gnu_toolchain_release/bd-uclibceb/gcc-stage2/arceb-snps-linux-uclibc/libstdc++-v3/include/ext/atomicity.h:82: undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)'
Instead of trying to patch the configure script as advocated by
Yann E. Morin, set LD to TARGET_CXX as:
- this solution is quicker
- usptream is dead (last release in 2016)
- this solution has already been used in other packages (nodejs, zmqpp)
[1]: https://patchwork.ozlabs.org/project/buildroot/patch/20200812171821.2517-1-Evgeniy.Didin@synopsys.com/
Fixes:
- http://autobuild.buildroot.org/results/6096c3ddc5edf3204635c2c90246c2e8c8e074e7
- http://autobuild.buildroot.org/results/d8a/d8a3ab31c5b86871c7e1117f4ffa7b6cedfcb7e0/build-end.log
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
