do_package for depot-tools fails with "file format not recognized" error.

[octonout]

Hi there. I have recently started with Yocto and flutter. I am trying to add the meta-flutter layer to my RPi 3B+ core-image-base.
This is my build config:

BB_VERSION           = "1.46.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "raspberrypi3"
DISTRO               = "poky"
DISTRO_VERSION       = "3.1.8"
TUNE_FEATURES        = "arm vfp cortexa7 neon vfpv4 thumb callconvention-hard"
TARGET_FPU           = "hard"
meta                 
meta-poky            
meta-yocto-bsp       = "dunfell:0abf6820292b8a6ac566db254ff8c9f76bf678b9"
meta-raspberrypi     = "dunfell:77190af02d48adc2b28216775e6318e9eeda571c"
meta-oe              
meta-multimedia      
meta-networking      
meta-python          = "dunfell:11eae114522a6befa06c7f4021a83bc016133543"
meta-flutter         = "dunfell:9d50ce85de4d249d3bdf194753d38276c567b949"
meta-customizations  = "<unknown>:<unknown>"

I tried to add multiple packages at once to IMAGE_INSTALL_append in my local.conf. That led to errors. I don't completely understand which packages I need to add. So to begin, I decided to test with:
IMAGE_INSTALL_append = " depot-tools"
do_fetch, do_compile and do_install execute fine, but do_package fails with the following error: pastebin

I tried bitbaking with INHIBIT_PACKAGE_STRIP = "1" added to local.conf / a bbappend for depot-tools. But that didn't help. Then some search results mentioned how this could be a compiler related issue.
From the error, arm-poky-linux-gnueabi-objcopy is being run with "--only-keep-debug". So I used readelf to check the header of python2.7 elf that objcopy is trying to strip. Turns out its compiled for x86_64. Here is the output:

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64

I took a look at the depot-tools recipe and I am not quite sure what I need to change in order to get an arm executable. Or is it supposed to be used for cross compilation on host? From the recipe, it looks like the repo is being checked out in ${WORKDIR}/git. do_compile exports some variables. And do_install copies stuff from ${WORKDIR}/git to ${bindir}. I would be really grateful if someone could help me understand what I can do to fix this.

Here's my local.conf: pastebin

P.S. The flutter documentation says that each platform requires a flutter embedder. Do I need to add meta-clang to the build in order to add flutter-pi package? If so, will adding meta-clang to bblayers.conf suffice, or will I need to make some changes elsewhere to make it work?

[jwinarske]

Hi,

depot-tools-native is used by flutter-engine recipe, it's not intended to be used on target. There are two types of recipes:

1. target
2. host aka -native

Also depending on what base image you are building you might want to use this in your conf/local.conf:

FLUTTER_CHANNEL="master"
CORE_IMAGE_EXTRA_INSTALL += " 
    flutter-pi \
    flutter-gallery \
"

It will build and install dependencies. You do not need to add anything else.

If you hit a failure at the link stage, then you are not using dunfell, and you need to override the GCC version as lightly referenced in the Readme. However if you are building for MACHINE=raspberrypi3 it won't make it to the link stage, as there is a bug building the flutter engine for arm (32-bit). If you changed your image to MACHINE=raspberrypi3-64 the flutter engine would successfully build, and run on target. Not to mention it would be more performant.

meta-clang is not needed to build the flutter-pi recipe, just for the Sony recipes. The clue is the presence of TOOLCHAIN = "clang" in the recipe.

If your end game is to use Yocto to generate a Raspbian-32 runtime, and you don't care about running an AOT (compiled) Flutter app, only an interpreted app, then you can hack up the flutter engine build to would around referenced bug.

I would suggest using dunfell branch as your baseline with raspberrypi3-64 as your machine type. Once you get that running, then deviate from a known working state.

[octonout]

flutter-engine is implicitly included in OS image, as flutter-pi is dependent on it. So no need to add it to the image.

Yeah, its in the DEPENDS variable for the flutter-pi as well as the flutter-gallery recipe. I hadn't included it while building the first time. But had to add it later on as the libflutter_engine.so is built but isn't included in the image if I don't.

This is generally managed via CI pipeline, but having a local build you don't build from scratch understanding the clearing order is helpful

Will keep this in mind.

The AOT image is installed to ${datadir}/${PN}/sony/lib, so you can create a symlink in your flutter_assets folder pointing to it, and then use the --release flag.

Yup. Did this and now the app starts. It isn't accepting any touch / keyboard / mouse input though. The embedder should be responsible for these right? Got to figure out if touch is even enabled. meta-raspberrypi docs suggest adding WAVESHARE_1024X600_C_2_1 = "1" to local.conf for enabling touch (link here). But I have got the Waveshare 800x480 7 inch Rev 3.1 model.

The raspberrypi3-64.conf file includes the rpi-base.inc which sets MACHINE_FEATURES to have touchscreen.
This needs some further digging. Will update if I find out how to make it work.

Edit 1: All WAVESHARE_1024X600_C_2_1 = "1" does is add the following to the /boot/config.txt:

max_usb_current=1
hdmi_group=2
hdmi_mode=87
hdmi_cvt 1024 600 60 6 0 0 0
hdmi_drive=1

Because my screen is different I had already added this using a .bbappend:

max_usb_current=1
hdmi_group=2
hdmi_mode=87
hdmi_cvt 800 480 60 6 0 0 0
hdmi_drive=1

So maybe touch is already enabled.

Edit 2:
Okay the touchscreen is accepting inputs.
There is a file for the touchscreen at "/dev/input/touchscreen" which is a symlink to "/dev/input/event1".
cat /dev/input/touchscreen and touching the touchscreen shows random characters on screen.

flutter-pi -i "/dev/input/event1" --dimensions "154,86" --release /usr/share/flutter-gallery/sony/data/flutter_assets/

Using the above command and touching the button on the top right corner in the flutter-gallery app gives the following output and error: pastebin
The same error will repeat on touching the button again. The other UI elements remain unresponsive to any touches or swipes.

[jwinarske]

The dimension should match the screen size. The touch should map 1:1 to screen size.

You should be able to eliminate the fontconfig error by adding fontconfig to the flutter-pi recipe DEPENDS statement. That's something I haven't seen, and may have been recently introduced.

The last error looks like flutter-pi is not handling a required platform channel; common issue with most of the embedders.

At this point you can create your own app recipe using flutter-gallery as a template, and you shouldn't get gallery specific errors.

Part of using a custom embedder is having to implement your platform channels, if used.

To use FFI from dart does not require this.

[jwinarske]

I updated the flutter-pi recipe with fontconfig depends.

[jwinarske]

The "right" way for flutter-pi and icudtl.dat is that I patch flutter-pi to load from ${datadir} path. icudtl.dat is not a library, it's a version specific data blob, potentially only relevant to libflutter_engine.so.

I just committed a patch to address this.

[octonout]

The dimension should match the screen size.

Is there a recommended way of calculating screen size? I used the LCD panel dimension document from the manufacturer's
website and used the dimensions marked in it. pic

The touch should map 1:1 to screen size.

Does flutter-pi itself map touch for you based on the provided dimensions?

You should be able to eliminate the fontconfig error by adding fontconfig to the flutter-pi recipe DEPENDS statement. That's something I haven't seen, and may have been recently introduced.

I pulled the changes you committed and rebuilt the image, but the fontconfig error persisted. Although I was able to solve it by bitbaking the fontconfig recipe and manually installing the package using opkg install. The fontconfig package has some other packages it depends on, which I again installed manually.
Shouldn't fontconfig be a part of RDEPENDS instead of DEPENDS? Cos its a runtime dependency for flutter-pi right? And maybe it should be the same for flutter-engine, cos the libflutter_engine.so is required at runtime.

At this point you can create your own app recipe using flutter-gallery as a template, and you shouldn't get gallery specific errors.

Gonna try this next.

Thanks!