Chromium doesn't compile because of the lack of sve support

[M1buKy0sh1r0]

NeddySeagoon,

in my case it is detected as:

[NeddySeagoon]

M1buKy0sh1r0,

True.

There is no change on a Pi5
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[hardhat]

The Chromium situation is worse on older ARMv8 processors. My board lacks SVE, SME, i8mm, and dotprod. If I were to enable arm_use_neon (for some reason this is not respected for CPU features in the ebuild) and therefore I have to do the following:

- libyuv_use_sme = false
- libyuv_use_sve = false
- LIBYUV_DISABLE_NEON_DOTPROD=1
- stop libaom, libgav1, and libdav1d from building
- libvpx fails here because I can't stop it from building at all

The accomodation for CPU flags in recent Chromium seems to be whack and halfassed.
Some of the bundled libraries are all hardcoded to expect later ARM revisions. There is no arm_use_neon_dotprod nor arm_use_sve, etc.

For example, libdav1d's preconfigured define headers expect v8.6 and newer.
Because they are headers we have to sed patch them if we are expected to make them bend to our will.

This bullshit is to be expected but it's sad that they neglect their older userbase.
So in the end I have to do arm_use_neon=false, and I don't even know if I'll run into any errors-- yet.

What happened to system-libvpx and system-av1 on Chromium, by the way? Those flags are now dead gone.

[Hu]

I have not discussed any of this post with the people who maintain Chromium in Gentoo.

As I read the gentoo.git history for www-client/chromium, chromium-117.0.5938.149.ebuild had support for USE=system-av1, but newer ebuilds do not. Presumably, this means that newer releases cannot work with the system version without more downstream effort than the Gentoo maintainer was willing to volunteer. It might be the case that this flag would come back if the upstream Chromium developers made it easier for Gentoo to switch to the system version.

I also found www-client/chromium unmask system-av1 ?, where a (now retired) Gentoo developer stated:

[hardhat]

That was exactly what I suspected... alas.

Also: only one wasted day later did I realize that arm_use_neon is not exposed to build configuration. D'oh!
At some point I will try to come up with an idea how to patch this stuff properly, but for now I'm going to stick with Firefox.

[NeddySeagoon]

hardhat,

neon on 32 bit arm and neon on 64 bit arm are completely different things.
That's a mess.

There has been some discussion about splitting CPU_FLAGS_ARM= into two, so CPU_FLAGS_ARM64= applied to aarch64 and CPU_FLAGS_ARM was for 32 bit only.
Nothing has happened yet.

Both neons would still be different.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[NeddySeagoon]

There is a horrible hacky patch in www-client/chromium-133.0.6943.27 build fails with ld.lld: error: undefined symbol: __arm_tpidr2_save that changes libyuv's CPU feature detection from one value of wrong to a different value of wrong that works on a Pi5,

It may point the way to similar hacky patches to support other arm64 feature sets.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.