All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Adam Duskett <adam.duskett@amarulasolutions.com>
Cc: Angelo Compagnucci <angelo@amarulasolutions.com>,
	Michael Trimarchi <michael@amarulasolutions.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Asaf Kahlon <asafka7@gmail.com>,
	buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH vRFC 3/3] package/flutter-engine: new package
Date: Sun, 23 Jul 2023 23:26:02 +0200	[thread overview]
Message-ID: <20230723212602.GC3544423@scaer> (raw)
In-Reply-To: <20230720233629.1642220-4-adam.duskett@amarulasolutions.com>

Adam, All,

On 2023-07-20 16:36 -0700, Adam Duskett spake thusly:
> 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 repository depends on the .git dirs being present.

s/flutter repository/flutter buildsystem/  maybe?

>   (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
> 
> - The clang toolchain wrapper does not work properly, resulting in the immediate
>   errors of:
>     -Wl,-z,now: 'linker' input unused
>     -Wl,-z,relro: 'linker' input unused

Those two are us adding them because of BR2_RELRO_FULL (-Wl,-z,relro
alone would be due to BR2_RELRO_PARTIAL).

It does recognise that they are linker options, but why are they
rejected? Do you have more context to provide?

>   The solution is to use clang.br_real and clang++.br_real.

Most probably not, because you lose a lot of the options set by
Buildroot (optimisation ,target CPU, etc...). The real solution is to
understand why -Wl-z-relro/now are rejected, and if they really are not
needed, to find a way to tell the toolchain wrapper not set them for
clang tools.

> - If using per_package builds, flutter-engine tries to use the host /usr/bin/ld
>   instead of the one provided by the compiler, resulting in linking errors.
>   As such, if BR2_PER_PACKAGE_DIRECTORIES is enabled, we search for the ld
>   provided by the compiler in the host directory and set the path accordingly.

Can this be related to the above -Wl issue?

> - libtessellator.so (built by flutter) requires three files:
>   crtbeginS.o crtendS.o libgcc.a. However, the toolchain path isn't referenced
>   when linking. The solution is to copy those three files to the staging lib
>   directory before building.
> 
> Tested with:
>   - Debian 11 and 12
>   - Ubuntu 18.04, 20.04, and 22.04
>   - Fedora 38
>   - Per package directory enabled and disabled
>   - x86_64, arm64
> 
> Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
> ---
[--SNIP--]
> diff --git a/package/flutter-engine/0001-disable-pre-canned-sysroot.patch b/package/flutter-engine/0001-disable-pre-canned-sysroot.patch
> new file mode 100644
> index 0000000000..c4064a77c9
> --- /dev/null
> +++ b/package/flutter-engine/0001-disable-pre-canned-sysroot.patch
> @@ -0,0 +1,32 @@
> +From 49a14e693124dc34f2cccbfb755d01a1198aa6bf Mon Sep 17 00:00:00 2001
> +From: Adam Duskett <adam.duskett@amarulasolutions.com>

You're not the author; Joel Winarske is. That's also the authorship
there is in the upstream issue you referenced.

[--SNIP--]
> diff --git a/package/flutter-engine/0002-remove-explicit-x11-dependency.patch b/package/flutter-engine/0002-remove-explicit-x11-dependency.patch
> new file mode 100644
> index 0000000000..1345d4a3dd
> --- /dev/null
> +++ b/package/flutter-engine/0002-remove-explicit-x11-dependency.patch
> @@ -0,0 +1,33 @@
> +From b1a5db9318ca33a03f2700758d5debad907d21b6 Mon Sep 17 00:00:00 2001
> +From: Adam Duskett <adam.duskett@amarulasolutions.com>

Ditto

> +Date: Wed, 19 Jul 2023 15:26:40 -0700
> +Subject: [PATCH] remove explicit x11 dependency
> +
> +This is redundant, as the gtk pkg-config query will reference x11 if that's how

Not so much redundant, but rather superfluous and may conflict with the
actual rendering system used in gtk3 (e.g. wayland).

> diff --git a/package/flutter-engine/0003-disable-undefined-version.patch b/package/flutter-engine/0003-disable-undefined-version.patch
> new file mode 100644
> index 0000000000..468ec4daf9
> --- /dev/null
> +++ b/package/flutter-engine/0003-disable-undefined-version.patch
> @@ -0,0 +1,32 @@
> +From 9512040259f3970dd5ca08fd9ebcfd42e7539997 Mon Sep 17 00:00:00 2001
> +From: Adam Duskett <aduskett@gmail.com>
> +Date: Tue, 18 Jul 2023 15:21:51 -0700
> +Subject: [PATCH] Disable undefined-version
> +
> +This isn't a valid flag for ld, and flutter compiles just fine with the
> +no-undefined-version flag.

Without that option, the linker will just ignore a symbol with an
undefined version. With the option, a smbol with an undefined version
turns into an error.

So indeed, without the option, the check is relaxed so it is not
surprising the build does not fail.

[--SNIP--]
> diff --git a/package/flutter-engine/Config.in b/package/flutter-engine/Config.in
> new file mode 100644
> index 0000000000..fe72191e77
> --- /dev/null
> +++ b/package/flutter-engine/Config.in
> @@ -0,0 +1,93 @@
> +config BR2_PACKAGE_FLUTTER_ENGINE_ARCH_SUPPORTS
> +	bool
> +	default y if BR2_aarch64
> +	default y if BR2_arm && !BR2_ARM_CPU_ARMV4 && !BR2_ARM_CPU_ARMV5
> +	default y if BR2_i386
> +	default y if BR2_x86_64

Since it uses clang, i'd also add: BR2_PACKAGE_LLVM_ARCH_SUPPORTS, but
this is a bit fuzzy for me what option we should add, if any...

> +
> +config BR2_PACKAGE_FLUTTER_ENGINE
> +	bool "flutter-engine"
> +	depends on BR2_PACKAGE_FLUTTER_ENGINE_ARCH_SUPPORTS
> +	depends on BR2_TOOLCHAIN_USES_GLIBC
> +	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_5
> +	depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL # pthreads
> +	depends on BR2_INSTALL_LIBSTDCPP
> +	depends on !BR2_TOOLCHAIN_HAS_GCC_BUG_64735 # std::shared_future
> +	depends on !BR2_STATIC_LIBS
> +	depends on BR2_USE_WCHAR # std::wstring
> +	depends on BR2_HOST_GCC_AT_LEAST_5
> +	depends on BR2_PACKAGE_HAS_LIBGL || BR2_PACKAGE_HAS_LIBGLES
> +	select BR2_PACKAGE_HOST_DEPOT_TOOLS
> +	select BR2_PACKAGE_FREETYPE
> +	select BR2_PACKAGE_ZLIB
> +	help
> +	  Flutter is Google's SDK for crafting beautiful, fast user
> +	  experience for mobile, web, and desktop from a single
> +	  codebase. Flutter works with existing code, is used by
> +	  developers and organizations around the world, and is
> +	  free and open source.
> +
> +	  The Flutter Engine is a portable runtime for hosting
> +	  Flutter applications. It implements Flutter's core
> +	  libraries, including animation and graphics, file and
> +	  network I/O, accessibility support, plugin architecture,
> +	  and a Dart runtime and compile toolchain. Most developers
> +	  will interact with Flutter via the Flutter Framework,
> +	  which provides a modern, reactive framework, and a rich
> +	  set of platform, layout and foundation widgets.
> +
> +	  https://github.com/flutter/engine
> +
> +if BR2_PACKAGE_FLUTTER_ENGINE
> +
> +choice
> +	prompt "Runtime mode"
> +	default BR2_PACKAGE_FLUTTER_ENGINE_RUNTIME_RELEASE

Mabye:
    default BR2_PACKAGE_FLUTTER_ENGINE_RUNTIME_DEBUG if BR2_ENABLE_RUNTIME_DEBUG
    default BR2_PACKAGE_FLUTTER_ENGINE_RUNTIME_RELEASE

Which brings up the question: do we need the profile mode in Buildroot,
or can we settle with just Release vs. Debug?

If so, then no need for this choice; just test BR2_ENABLE_RUNTIME_DEBUG
in flutter.mk

[--SNIP--]
> diff --git a/package/flutter-engine/flutter-engine.mk b/package/flutter-engine/flutter-engine.mk
> new file mode 100644
> index 0000000000..aa392a31d8
> --- /dev/null
> +++ b/package/flutter-engine/flutter-engine.mk
> @@ -0,0 +1,286 @@
> +################################################################################
> +#
> +# flutter-engine
> +#
> +################################################################################
> +
> +# Flutter-engine has a release on the GitHub page. However, that release is
> +# only for Google. Its intended purpose is for the gclient tool provided by
> +# Google in their depot-tools package. To use the source code, we must use
> +# gclient to download the flutter-engine source code along with several other
> +# projects. Unfortunately, the Buildroot download system does not have the
> +# capability of using gclient, and considering this package is the only
> +# package that uses gclient, we side-step the entire download process and
> +# perform the following steps if a tarball does not exist already:
> +#
> +#  - Copy the pre-made gclient config file to a temporary download
> +#    directory.
> +#  - Run gclient sync to generate a source directory with the proper
> +#    flutter-engine source code in the correct places.
> +#  - Run mk_tar_gz to create a tarball.
> +#  - Copy the tarball to $(FLUTTER_ENGINE_DL_DIR)
> +#    directory to create a reproducible tarball.
> +#
> +# There is no hash provided, as the gn binary (used for configuration) relies
> +# on the .git directories, so there is no way to make reproducible tarballs.
> +FLUTTER_ENGINE_VERSION = 3.10.6
> +
> +# There is nothing for Buildroot to download. This is handled by gclient.
> +FLUTTER_ENGINE_SITE =
> +FLUTTER_ENGINE_SOURCE =
> +FLUTTER_ENGINE_LICENSE = BSD-3-Clause
> +FLUTTER_ENGINE_LICENSE_FILES = LICENSE
> +FLUTTER_ENGINE_TARBALL_PATH = $(FLUTTER_ENGINE_DL_DIR)/flutter-$(FLUTTER_ENGINE_VERSION).tar.gz
> +FLUTTER_ENGINE_INSTALL_STAGING = YES
> +FLUTTER_ENGINE_DOWNLOAD_DEPENDENCIES = host-depot-tools
> +FLUTTER_ENGINE_DEPENDENCIES = \
> +	host-clang \
> +	host-ninja \
> +	host-pkgconf \
> +	freetype \
> +	zlib
> +
> +# Dispatch all architectures of flutter
> +ifeq ($(BR2_i386),y)
> +FLUTTER_ENGINE_TARGET_ARCH = x86
> +FLUTTER_ENGINE_TARGET_TRIPPLE = x86-linux
> +else ifeq ($(BR2_x86_64),y)
> +FLUTTER_ENGINE_TARGET_ARCH = x64
> +FLUTTER_ENGINE_TARGET_TRIPPLE = x86_64-linux
> +else ifeq ($(BR2_arm)$(BR2_armeb),y)
> +FLUTTER_ENGINE_TARGET_ARCH = arm
> +FLUTTER_ENGINE_TARGET_TRIPPLE = arm-linux
> +else ifeq ($(BR2_aarch64),y)
> +FLUTTER_ENGINE_TARGET_ARCH = arm64
> +FLUTTER_ENGINE_TARGET_TRIPPLE = aarch64-linux
> +endif
> +
> +ifeq ($(BR2_PACKAGE_FLUTTER_ENGINE_RUNTIME_RELEASE),y)
> +FLUTTER_ENGINE_RUNTIME_MODE=release
> +else ifeq ($(BR2_PACKAGE_FLUTTER_ENGINE_RUNTIME_PROFILE),y)
> +FLUTTER_ENGINE_RUNTIME=profile
> +else
> +FLUTTER_ENGINE_RUNTIME=debug
> +endif
> +
> +FLUTTER_ENGINE_BUILD_DIR = \
> +	$(@D)/out/linux_$(FLUTTER_ENGINE_RUNTIME_MODE)_$(FLUTTER_ENGINE_TARGET_ARCH)
> +
> +FLUTTER_ENGINE_INSTALL_FILES = libflutter_engine.so libflutter_linux_gtk.so
> +
> +FLUTTER_ENGINE_CONF_OPTS = \
> +	--clang \
> +	--depot-tools $(HOST_DIR)/share/depot_tools \
> +	--embedder-for-target \
> +	--linux-cpu $(FLUTTER_ENGINE_TARGET_ARCH) \
> +	--no-build-embedder-examples \
> +	--no-clang-static-analyzer \
> +	--no-enable-unittests \
> +	--no-goma \
> +	--no-prebuilt-dart-sdk \
> +	--runtime-mode $(FLUTTER_ENGINE_RUNTIME_MODE) \
> +	--target-os linux \
> +	--target-sysroot $(STAGING_DIR) \
> +	--target-toolchain $(HOST_DIR) \
> +	--target-triple $(FLUTTER_ENGINE_TARGET_TRIPPLE)
> +
> +ifeq ($(BR2_arm)$(BR2_armeb),y)
> +FLUTTER_ENGINE_CONF_OPTS += \
> +	--arm-float-abi $(call qstrip,$(BR2_GCC_TARGET_FLOAT_ABI))
> +endif
> +
> +ifeq ($(BR2_PACKAGE_FLUTTER_ENGINE_ARTIFACTS),y)
> +FLUTTER_ENGINE_CONF_OPTS += --build-engine-artifacts
> +else
> +FLUTTER_ENGINE_CONF_OPTS += --no-build-engine-artifacts
> +endif
> +
> +ifeq ($(BR2_OPTIMIZE_0),y)
> +FLUTTER_ENGINE_CONF_OPTS += --unoptimized
> +endif
> +
> +ifeq ($(BR2_ENABLE_LTO),y)
> +FLUTTER_ENGINE_CONF_OPTS += --lto
> +else
> +FLUTTER_ENGINE_CONF_OPTS += --no-lto
> +endif
> +
> +ifeq ($(BR2_STRIP_strip),y)
> +FLUTTER_ENGINE_CONF_OPTS += --stripped
> +else
> +FLUTTER_ENGINE_CONF_OPTS += --no-stripped
> +endif
> +
> +ifeq ($(BR2_PACKAGE_FONTCONFIG),y)
> +FLUTTER_ENGINE_DEPENDENCIES += fontconfig
> +FLUTTER_ENGINE_CONF_OPTS += --enable-fontconfig

    else
    FLUTTER_ENGINE_CONF_OPTS += --disable-fontconfig

> +endif
> +
> +ifeq ($(BR2_PACKAGE_HAS_LIBGL),y)
> +FLUTTER_ENGINE_DEPENDENCIES += libgl
> +endif
> +
> +ifeq ($(BR2_PACKAGE_HAS_LIBGLES),y)
> +FLUTTER_ENGINE_DEPENDENCIES += libgles
> +endif
> +
> +ifeq ($(BR2_PACKAGE_MESA3D),y)
> +FLUTTER_ENGINE_DEPENDENCIES += mesa3d
> +endif
> +
> +ifeq ($(BR2_PACKAGE_MESA3D_VULKAN_DRIVER),y)
> +FLUTTER_ENGINE_CONF_OPTS += --enable-vulkan

    else
    FLUTTER_ENGINE_CONF_OPTS += --diable-vulkan

> +endif
> +
> +ifneq ($(BR2_PACKAGE_XORG7)$(BR2_PACKAGE_LIBXCB),yy)

Prefer positive logic:

    ifeq ($(BR2_PACKAGE_XORG7)$(BR2_PACKAGE_LIBXCB),yy)
    FLUTTER_ENGINE_DEPENDENCIES += libxcb
    else
    [the hack]
    endif

> +define FLUTTER_ENGINE_VULKAN_X11_SUPPORT_FIXUP
> +	$(SED) "s%vulkan_use_x11.*%vulkan_use_x11 = false%g" -i \
> +		$(@D)/build_overrides/vulkan_headers.gni
> +endef
> +FLUTTER_ENGINE_PRE_CONFIGURE_HOOKS += FLUTTER_ENGINE_VULKAN_X11_SUPPORT_FIXUP
> +else
> +FLUTTER_ENGINE_DEPENDENCIES += libxcb
> +endif
> +
> +ifneq ($(BR2_PACKAGE_WAYLAND),y)

Ditto, positive logic please.

> +define FLUTTER_ENGINE_VULKAN_WAYLAND_SUPPORT_FIXUP
> +	$(SED) "s%vulkan_use_wayland.*%vulkan_use_wayland = false%g" \
> +		$(@D)/build_overrides/vulkan_headers.gni
> +endef
> +FLUTTER_ENGINE_PRE_CONFIGURE_HOOKS += FLUTTER_ENGINE_VULKAN_WAYLAND_SUPPORT_FIXUP
> +else
> +FLUTTER_ENGINE_DEPENDENCIES += wayland
> +endif
> +
> +ifeq ($(BR2_PACKAGE_LIBGTK3),y)
> +FLUTTER_ENGINE_DEPENDENCIES += libgtk3
> +else
> +FLUTTER_ENGINE_CONF_OPTS += --disable-desktop-embeddings
> +endif
> +
> +ifeq ($(BR2_PACKAGE_LIBGLFW),y)
> +FLUTTER_ENGINE_DEPENDENCIES += libglfw
> +FLUTTER_ENGINE_CONF_OPTS += --build-glfw-shell
> +else
> +FLUTTER_ENGINE_CONF_OPTS += --no-build-glfw-shell
> +endif
> +
> +# The clang toolchain wrapper causes a lot of the following errors:
> +# error: -Wl,-z,now: 'linker' input unused [-Werror,-Wunused-command-line-argument]
> +# error: -Wl,-z,relro: 'linker' input unused [-Werror,-Wunused-command-line-argument]

Ah, that's because linker options are passed when we are not linking but
just compiling. And that's an error because of -Werror!

Can we disable -Werror instead of skipping the wrappers?

> +# Excplicitly use the real clang binaries for cc and cxx.
> +ifeq ($(BR2_CCACHE),y)
> +define FLUTTER_ENGINE_COMPILER_PATH_FIXUP
> +	$(SED) "s%cc =.*%cc = \"\$${toolchain_bin}/ccache clang.br_real\""%g \
> +		$(@D)/build/toolchain/custom/BUILD.gn
> +
> +	$(SED) "s%cxx =.*%cxx = \"\$${toolchain_bin}/ccache clang++.br_real\""%g \
> +		$(@D)/build/toolchain/custom/BUILD.gn
> +endef
> +else
> +define FLUTTER_ENGINE_COMPILER_PATH_FIXUP
> +	$(SED) "s%cc =.*%cc = \"\$${toolchain_bin}/clang.br_real\""%g \
> +		$(@D)/build/toolchain/custom/BUILD.gn
> +
> +	$(SED) "s%cxx =.*%cxx = \"\$${toolchain_bin}/clang++.br_real\""%g \
> +		$(@D)/build/toolchain/custom/BUILD.gn
> +endef
> +endif
> +FLUTTER_ENGINE_PRE_CONFIGURE_HOOKS += FLUTTER_ENGINE_COMPILER_PATH_FIXUP
> +
> +# If using per_package builds, flutter-engine tries to use the /usr/bin/ld instead of
> +# the one provided by the compiler, resulting in linking errors.
> +ifeq ($(BR2_PER_PACKAGE_DIRECTORIES),y)
> +define FLUTTER_ENGINE_GET_PATH
> +	(ld_bin_path=$$(dirname $$(realpath $$(find $(PER_PACKAGE_DIR)/flutter-engine -name ld -type f))); \
> +		echo $${ld_bin_path}:$(BR_PATH):$(HOST_DIR)/share/depot_tools; \
> +	)
> +endef
> +else
> +define FLUTTER_ENGINE_GET_PATH
> +		echo $(BR_PATH):$(HOST_DIR)/share/depot_tools
> +endef
> +endif
> +
> +# Generate a tarball if one does not already exist.
> +define FLUTTER_ENGINE_GENERATE_TARBALL
> +	(if [ ! -e $(FLUTTER_ENGINE_TARBALL_PATH) ]; then \

Don't use a subshell here (parenthesis are toally unneeded and
superfluous).

> +		. ./support/download/helpers && \
> +		rm -rf $(@D)/dl-tmp && mkdir -p $(@D)/dl-tmp && \
> +		$(INSTALL) -D -m 0755 $(FLUTTER_ENGINE_PKGDIR)/gclient \

This is not gclient, this is .gclient, but having a source fiel that is
a dot-file in the tree is not nice. Can we just name it dot-gclient
instead:

    $(FLUTTER_ENGINE_PKGDIR)/dot-gclient

> +			$(@D)/dl-tmp/.gclient && \
> +		$(SED) "s%!FLUTTER_VERSION!%$(FLUTTER_ENGINE_VERSION)%g" \
> +			$(@D)/dl-tmp/.gclient && \
> +		cd $(@D)/dl-tmp && \
> +		$(DEPOT_TOOLS_GCLIENT) \
> +			sync \
> +			--delete_unversioned_trees \
> +			-j$(PARALLEL_JOBS) \
> +			--no-history \
> +			--reset \
> +			--shallow && \
> +		mkdir -p $(FLUTTER_ENGINE_DL_DIR); \
> +		cd $(@D)/dl-tmp && \
> +		mk_tar_gz \
> +		$(@D)/dl-tmp/src \
> +		flutter-$(FLUTTER_ENGINE_VERSION) \
> +		"$$(git -C $(@D)/dl-tmp/src log -1 --pretty=format:%ci)" \
> +		$(FLUTTER_ENGINE_TARBALL_PATH) && \
> +		rm -rf $(@D)/dl-tmp; \
> +	fi \
> +	)

I think this big if-block should go into a helper script (yeah, yeah., I
may have written something using make code in my earlier suggestion, but
that was not smart of me...)

So:
    define FLUTTER_ENGINE_GENERATE_TARBALL
        $(FLUTTER_PKGDIR)/gen-tarball \
            --version $(FLUTTER_ENGINE_VERSION) \
            --tarball $(FLUTTER_ENGINE_TARBALL_PATH) \
            --dot-gclient $(FLUTTER_ENGINE_PKGDIR)/dot-gclient \
            --scratch-dir $(@D)/dl-tmp
    endef

And then a sequence of complex script shell is easier to write, to
review, and to maintain.

> +endef
> +FLUTTER_ENGINE_POST_DOWNLOAD_HOOKS += FLUTTER_ENGINE_GENERATE_TARBALL
> +
> +define FLUTTER_ENGINE_EXTRACT_CMDS
> +	gzip -d -c $(FLUTTER_ENGINE_TARBALL_PATH) | tar --strip-components 1 -C $(@D) -xf -
> +endef
> +
> +define FLUTTER_ENGINE_CONFIGURE_CMDS
> +  # libtessellator requires these three files, but the toolchain path isn't
> +  # referenced when linking. Copy them to the staging lib directory before
> +  # building.
> +	$(Q)$(foreach i,crtbeginS.o crtendS.o libgcc.a,
> +		$(Q)if [ ! -e $(STAGING_DIR)/usr/lib/$(i) ]; then \
> +			file_path=$$(find $(HOST_DIR) -type f -name $(i)); \

This is going to be a bit more complex than that, because of multi-lib
or multi-arch external toolchains. See the mess it is to find the
sysroot in toolchain/helpers.mk

But seriously though, why are they not brought in? Did you try to run
the linking command manually in debug mode (--verbose if calling ld
directly, of -Wl.--verbose if using gcc to link)?

Is it using ld to do the link, or is it using gcc?

Is ld binutils', or is it lld? This might also have a link as to why
-Wl,-z,now and -Wl,-z,relro are not supported...

> +			$(INSTALL) -D -m 0755 $${file_path} $(STAGING_DIR)/usr/lib/$(i); \
> +		fi \
> +	)
> +	(cd $(@D)/ && \
> +		rm -rf $(FLUTTER_ENGINE_BUILD_DIR) && \
> +		PATH=$(shell $(call FLUTTER_ENGINE_GET_PATH)) \
> +		./flutter/tools/gn $(FLUTTER_ENGINE_CONF_OPTS) \
> +	)
> +endef
> +
> +define FLUTTER_ENGINE_BUILD_CMDS
> +	(cd $(@D); \
> +		PATH=$(shell $(call FLUTTER_ENGINE_GET_PATH)) \
> +		PYTHONNOUSERSITE=y \
> +		$(HOST_DIR)/bin/ninja \
> +			-j $(PARALLEL_JOBS) \
> +			-C $(FLUTTER_ENGINE_BUILD_DIR) \
> +	)
> +endef
> +
> +define FLUTTER_ENGINE_INSTALL_STAGING_CMDS
> +	$(foreach i,$(FLUTTER_ENGINE_INSTALL_STAGING_FILES),

Err... FLUTTER_ENGINE_INSTALL_STAGING_FILES is set nowhere?

Regards,
Yann E. MORIN.

> +		$(Q)if [ -e $(FLUTTER_ENGINE_BUILD_DIR)/$(i) ]; then \
> +			$(INSTALL) -D -m 0755 $(FLUTTER_ENGINE_BUILD_DIR)/$(i) \
> +				$(STAGING_DIR)/usr/lib/$(i); \
> +		fi \
> +	)
> +	$(INSTALL) -D -m 0755 $(FLUTTER_ENGINE_BUILD_DIR)/flutter_embedder.h \
> +		$(STAGING_DIR)/usr/include/flutter_embedder.h
> +endef
> +
> +define FLUTTER_ENGINE_INSTALL_TARGET_CMDS
> +	$(foreach i,$(FLUTTER_ENGINE_INSTALL_FILES),
> +		$(Q)if [ -e $(FLUTTER_ENGINE_BUILD_DIR)/$(i) ]; then \
> +			$(INSTALL) -D -m 0755 $(FLUTTER_ENGINE_BUILD_DIR)/$(i) \
> +				$(TARGET_DIR)/usr/lib/$(i); \
> +		fi \
> +	)
> +endef
> +
> +$(eval $(generic-package))
> diff --git a/package/flutter-engine/gclient b/package/flutter-engine/gclient
> new file mode 100644
> index 0000000000..168e9a368d
> --- /dev/null
> +++ b/package/flutter-engine/gclient
> @@ -0,0 +1,16 @@
> +# This file is taken from the output of meta-flutter/lib/gn.py
> +
> +solutions = [{
> +    "managed": False,
> +    "name": "src/flutter",
> +    "url": "https://github.com/flutter/engine.git@!FLUTTER_VERSION!",
> +    "custom_vars": {
> +        "download_android_deps": False,
> +        "download_windows_deps": False,
> +        "download_linux_deps": False
> +    },
> +    "custom_deps": {
> +        "src/third_party/dart/third_party/pkg/tools":
> +        "https://dart.googlesource.com/tools.git@unified_analytics-v1.1.0"
> +    }
> +}]
> -- 
> 2.41.0
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2023-07-23 21:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-20 23:36 [Buildroot] [PATCH vRFC 0/3] Initial flutter packages Adam Duskett
2023-07-20 23:36 ` [Buildroot] [PATCH vRFC 1/3] package/python-httplib2: add host variant Adam Duskett
2023-07-20 23:36 ` [Buildroot] [PATCH vRFC 2/3] package/depot-tools: new package Adam Duskett
2023-07-23 19:52   ` Yann E. MORIN
2023-07-20 23:36 ` [Buildroot] [PATCH vRFC 3/3] package/flutter-engine: " Adam Duskett
2023-07-23 21:26   ` Yann E. MORIN [this message]
2023-07-25 15:38     ` Adam Duskett
2023-07-20 23:37 ` [Buildroot] [PATCH vRFC 0/3] Initial flutter packages Adam Duskett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230723212602.GC3544423@scaer \
    --to=yann.morin.1998@free.fr \
    --cc=adam.duskett@amarulasolutions.com \
    --cc=angelo@amarulasolutions.com \
    --cc=asafka7@gmail.com \
    --cc=buildroot@buildroot.org \
    --cc=michael@amarulasolutions.com \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.