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

[M1buKy0sh1r0]

NeddySeagoon,

in my case it is detected as:

Code: Select all

-march=armv8-a+dotprod+i8mm

This may did the trick on the apple m1 only.

[NeddySeagoon]

M1buKy0sh1r0,

True.

There is no change on a Pi5

[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:

Chromium uses internal API of libaom. Bundled ffmpeg has modifications required for compiling Chromium.

From this, I would infer that there is more work - maybe much more work - involved than merely deleting the bundled copy and passing some flags to point to the system version.

[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.

[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.

[Kangie]

Hi,

The real issue here is the use of '-march' in CFLAGS in your chromium build. This whole "unbundle toolchain" is barely supported upstream, and for some reason libyuv (when built in chromium, it seems fine if built standalone...) does not strip '-march' when it is building units that have specific '-march' requirements (as in this case, where it's building a library that uses runtime detection to determine whether to enable a path containing these instructions).

In the short term Neddy's patch is probably fine, or an env which does not set '-march' options for Chromium until this is resolved.

I would subscribe to the bug for updates; I need to find time to do some more diagnosis and submit an upstream bug.

[NeddySeagoon]

Kangie

-march or -mcpu makes Chromium break. I gave up setting -march on arm64 when the Pi3 was new as breakage was quite common. -mcpu was UK.

I use

Code: Select all

 
# Chromium at least, is broken with -march or -mcpu
# Unset it on a per package basis
# COMMON_FLAGS="-mcpu=cortex-a76+crc+crypto -O2 -pipe -mtune=cortex-a76 -mbranch-protection=standard"
CFLAGS="-O2 -pipe -mtune=cortex-a76 -mbranch-protection=standard"
CXXFLAGS="-O2 -pipe -mtune=cortex-a76 -mbranch-protection=standard"

and

Code: Select all

 
www-client/chromium no-mcpu

without the libyuv patch now.

I think

Code: Select all

-mbranch-protection=standard

is a hangover from jumping the gun on the /23.0/ profile before the arm64 version was ready.

[Kangie]

Revisiting this: you're correct.

There are several components within chromium that build CPU-optimised units and then use runtime detection to select a codepath. Unfortunately the Chromium build system always puts custom

Code: Select all

CFLAGS

_after_ any unit-specific compiler flags (which is normally desirable), but in this case is causing issues.

Some, like

Code: Select all

libyuv

have handy toggles that we could wire up to

Code: Select all

CPU_FLAGS

and disable features we don't want to compile. Unfortunately others (like

Code: Select all

libvpx

don't have any toggles and I really don't think upstream care enough about it. I also note that somehow this works on amd64 (because the "floor" is higher?), but would fail exactly the same way there.

I'm honestly leaning towards filtering out

Code: Select all

-m{arch,tune,cpu}

on aarch64 at this point. It's the best solution in terms of user-experience, and as we've been able to identify here Upstream are already optimising taking advantage of CPU instructions / features in areas like media decoding (automatically) where it makes sense to do so.