Build error, looking for tips

I’m trying to get v1-q compiled for a pixel3a (sargo). There is unofficial support for Lineage 17.1 so it shouldn’t be “too difficult”… Famous last words…
I’ve got all the dependencies sorted out but the build fails near the 50% mark with:

hardware/qcom/audio/default/post_proc/volume_listener.c:29:10: fatal error: 'platform_api.h' file no
t found
#include <platform_api.h>
         ^~~~~~~~~~~~~~~~

Does anyone have suggestions for where to start looking before I dive down the rabbit hole and try to understand where what code comes from and how it looks on another device that builds?
NB: I’m using the docker build method.

Update: looks like this may have to do with hardware/qcom/audio/default in /e/ vs. hardware/qcom/audio in lineageOS:

build-e> egrep qcom/audio .repo/manifests/default.xml
  <project dest-branch="v1-q" groups="qcom,qcom_audio,pdk-qcom" name="e/os/android_hardware_qcom_audio" path="hardware/qcom/audio/default" remote="e" revision="81f555fe11a34c7970a4c564b5642f9e9e9ce47f" upstream="v1-q"/>

vs.

build-lineage> egrep qcom/audio .repo/manifests/default.xml
  <project path="hardware/qcom/audio" name="LineageOS/android_hardware_qcom_audio" groups="qcom,qcom_audio,pdk-qcom" />

the q sources of eOS as far away from complete. They are in a relay alpha stadium. Trying to build with it is a pain.

Ah, thanks, I had no idea, that would have never occurred to me :crazy_face:

I just moved the directory and so far the build seems to have passed the point where it failed before… It may be a bug in the e manifest xml…

please keep in mind, that all goolag calls are still available in eOS q sources. So in the moment, the difference to LOS is not much big

Oh wow, I didn’t know that point. Thanks for the info @harvey186

So it would be essentially the same as if we had LineageOS from here (with microG)…

https://download.lineage.microg.org/

yes, but with eOS default apps.

In my Q-GSI build I have removed a lot manually

Are you wiling to post at least a bullet list for where you found them and how you fixed them?

I managed to get a build compiled after renaming the dir. Except that it failed at the end not being able to fit stuff into one of the partitions:

lpmake E 08-29 09:54:44 453592 453592 builder.cpp:568] [liblp]Partition product is part of group
google_dynamic_partitions which does not have enough space free (334921728 requested, 3741548544 used
out of 4068474880)
Not enough space on device for partition product with size 334921728
2020-08-29 09:54:44 - add_img_to_target_files - ERROR   :

I guess now I need to figure out how to change the partition sizes???

Better remove system apps from /prebuilds/priv-apps and /packages/apps

Good suggestion. Do you know which are the biggest space hogs and where I make that change?

(Looks like I need to free up 8MB)

Start with magicEarth. Than OpenCamera, OpenKeyChain

Good suggestions. Can you give me a pointer for where to make those changes?

See my post before Build error, looking for tips

Hmmm, I have neither dir in my builds, weird. There must be a config file for what ends up there, right? Do you know where that is?

Oops, I had overlooked that, thanks for pointing it out.

Update: answering my own question: vendor/lineage/config/common.mk

Well, leaving MagicEarth and LibreOffice out of the build made exactly zero difference :frowning: . They were in the system partition and I suspect the size of that is not dependent on the contents.

After some tweaking of BOARD_SYSTEMIMAGE_PARTITION_RESERVED_SIZE:

#### build completed successfully (54:35 (mm:ss)) ####

Now I have to find an opportune moment to flash this stuff and see how loud my phone screams! :crazy_face:

there is an issue since month for it in Gitlab. There are several people which have the same issue. For example, my bacon pie builds aren’t finishing since beginning of the yer because of this error. I have removed ALL system apps and the build still fails.

Well, as you can see, it’s possible to get it to work :wink:
Can you paste a link to the issue you’re talking about?

Yes, that’s right, but not practicable for ‘normal’ users.

Here the issue https://gitlab.e.foundation/e/backlog/-/issues/1172#note_50170

1 Like