Add support for riscv64 desktop linux engine - #178712

@vhaudiquet
This patch set is required for a proper risc-v 32/64 engine build:
https://github.com/meta-flutter/workspace-automation/tree/v2.0/patches/flutter-engine

Also found here:
https://github.com/meta-flutter/meta-flutter/tree/master/recipes-graphics/flutter-engine/files

They’ve been around since August of last year.

Two key issues:

• engine needs to update llvm toolchain (cipd)
• third_party deps need updates (before this repo)

committing flutter changes without the above two is a bit of a hack.

I've only had to apply a patch to third_party swiftshader (as explained above). Other patches seem to have already been applied, or to not be necessary anymore?

I did not need anything except the swiftshader patch and this PR to build the engine.

Did the llvm cipd get updated recently? If so in what version. Patches referenced are for stable (3.57.7) + llvm 21.

I would think so, as effectively I tried applying my PR to the latest stable and it failed to build, so that one needed more patches.
It might be related to the recently merged PRs that provide a Flutter engine for riscv64 Android.

@robert-ancell This allows cross-compiling the engine on an x86_64 host for a riscv64 target, so you don't technically need a riscv64 builder to do that. But to run that engine, you are right that you need a riscv64 host; for which I think all of the community understands that the support is experimental. But maybe we can still add a message somewhere?

I see now that the "Google testing" failed. The test page says

Internal tests failed. Please contact a Google developer to help investigate the failure.

Can somebody help with that? 😃

Ping @jtmcdole on landing and testing this.

Hello @jtmcdole, happy new year! 😃
Any updates? Is there anything still misssing?

Back from holidays, let me take a look

Now that the tool PR has landed, is there a timeline for this one?

So right now, lets look at landing this; then get a patch in; then consider a x64 builder that can make artifacts at head.

If I can help getting the patch in for third_party/swiftshader, tell me 😃
I didn't know it was possible to patch this directly for Flutter usage. Also, I can help testing resulting artifacts, and testing everything basically, on RISC-V hardware. Let me know

Now that the tool PR has landed, is there a timeline for this one?

So right now, lets look at landing this; then get a patch in; then consider a x64 builder that can make artifacts at head.

If I can help getting the patch in for third_party/swiftshader, tell me 😃 I didn't know it was possible to patch this directly for Flutter usage. Also, I can help testing resulting artifacts, and testing everything basically, on RISC-V hardware. Let me know

The PR description says "For now, building the engine on RISC-V still requires another patch:" - since we'd be building this on x86, are we blocked waiting on this patch?

@jason-simmons - can you help with how we would maintain a flutter-specific patch for:

diff --git a/src/Reactor/BUILD.gn b/src/Reactor/BUILD.gn
index 67dfeb0ec..dcb13614a 100644
--- a/src/Reactor/BUILD.gn
+++ b/src/Reactor/BUILD.gn
@@ -307,7 +307,7 @@ if (supports_subzero) {

 if (supports_llvm) {
   swiftshader_source_set("swiftshader_llvm_reactor") {
-    llvm_dir = "../../third_party/llvm-10.0"
+    llvm_dir = "../../third_party/llvm-16.0"

     deps = [
       ":swiftshader_reactor_base",

The SwiftShader upstream tried to land that patch 2 years ago. But apparently it was reverted due to an incompatibility with Chromium.
(see https://swiftshader.googlesource.com/SwiftShader/+/eb75201a4e0354a36d315dd01077092ec9aa2356)

If we want to use that patch in Flutter, then that would involve creating a mirror of SwiftShader on https://flutter.googlesource.com/ and adding the patch to a branch.

The PR description says "For now, building the engine on RISC-V still requires another patch:" - since we'd be building this on x86, are we blocked waiting on this patch?

Sorry, I meant for RISC-V. We will need that patch if we want to merge and build at the same time.

i've created a mirror. I'll see about landing the patch there and then updating DEPs.

Hey @jtmcdole this hasn't been updated in a while but is approved, are we still sitting on this?

Hey @jtmcdole this hasn't been updated in a while but is approved, are we still sitting on this?

The idea was to merge that and also start to build the engine for riscv64 at the same time.
Unfortunately, building the engine still requires a patch to third_party/swiftshader, so @jtmcdole opened #181225 to add that patch.

The issue is that #181225 causes another problem, as it breaks builds on different cases, I'm not sure where (multiple tests are failing in CI, I think there are real failures on Windows and maybe others). I tried to reproduce locally but even with the swiftshader patch of #181225 the builds I tried did work 😃

I think there was a lack of time to debug that further, which is why the PR is still in this dangling state.

still waiting on the patch from @jtmcdole, I've pinged him on that pr

@jtmcdole friendly ping

third_party/swiftshader doesn't build for me on infra. I've not had time to look into what is missing to get that building from the mirror. I can try an update the mirror / patch set sometime this week.

third_party/swiftshader doesn't build for me on infra. I've not had time to look into what is missing to get that building from the mirror. I can try an update the mirror / patch set sometime this week.

it does now.

Hi @jtmcdole, thank you for your work on this!
What is left now to merge this one?
If needed, I can rebase this on top of master, and retry a build? Or do we want to get it in first, and land fixups later if the engine builds are not working? I will anyway try to find time this week to test an engine build with the new updated third_party/swiftshader.

I think a rebase and we should be able to review it, @vhaudiquet

I have rebased on top of master.

I have retested a build, which works, but only after others small patches.

• (1) Unfortunately, it seems that a workaround used in engine/src/flutter/shell/platform/linux/fl_view_accessible.cc breaks the build on trixie sysroots; and right now only riscv64 uses trixie (from the previous Flutter Android riscv64 builds, not this PR). Reading the workaround description, @robert-ancell is the one who fixed this upstream; but the fix has not made it into trixie (only in trixie-backports).
  We need a different workaround for trixie, as the code inside atk.h now uses real C++ features, so putting it all inside extern C is not possible. The more surgical fix is to only apply @robert-ancell fix to atkversion.h, but that file is not tracked in Git here... it is only inside the sysroot pulled by gclient.

  // Remove the old workaround that puts everything behind "extern C"
  diff --git a/engine/src/flutter/shell/platform/linux/fl_view_accessible.cc b/engine/src/flutte
  r/shell/platform/linux/fl_view_accessible.cc
  index df3a986ab9f..95cd63fe17f 100644
  --- a/engine/src/flutter/shell/platform/linux/fl_view_accessible.cc
  +++ b/engine/src/flutter/shell/platform/linux/fl_view_accessible.cc
  @@ -4,9 +4,7 @@
  
  - // Workaround missing C code compatibility in ATK header.
  - // Fixed in https://gitlab.gnome.org/GNOME/at-spi2-core/-/merge_requests/219
  -extern "C" {
   #include <atk/atk.h>
  -}
  
   #include "flutter/shell/platform/linux/fl_accessible_node.h"
   #include "flutter/shell/platform/linux/fl_accessible_text_field.h"

  // Surgically fix atkversion.h inside the sysroot
  --- a/engine/src/build/linux/debian_bullseye_amd64-sysroot/usr/include/atk-1.0/atk/atkversion.h
  +++ b/engine/src/build/linux/debian_bullseye_amd64-sysroot/usr/include/atk-1.0/atk/atkversion.h
  @@ -30,6 +30,8 @@
  
   #include <glib.h>
  
  +extern "C" {
  +
   /**
    * ATK_MAJOR_VERSION:
  @@ -474,5 +476,7 @@
   #define atk_interface_age atk_get_interface_age ()
  
  +}
  +
   #endif /* __ATK_VERSION_H__ */

• (2) A second issue seems to come from the fact that Dart SDK is built from source here (as there are no published dart riscv64 tarballs AFAIK). Because of that, something related to wasm-opt seems to break (unfamiliar with how it works exactly).

  diff --git a/engine/src/flutter/tools/gn b/engine/src/flutter/tools/gn
  index b7c34d8cc89..a97eed32fe6 100755
  --- a/engine/src/flutter/tools/gn
  +++ b/engine/src/flutter/tools/gn
  @@ -719,6 +719,16 @@ def to_gn_args(args):
       # dartdevc, web SDK kernel and source files.
       gn_args['dart_platform_sdk'] = not args.full_dart_sdk
  
  +  # When the Dart SDK is built from source (i.e. no usable prebuilt is
  +  # available for the target, such as for riscv64 Linux cross builds), exclude
  +  # the wasm-opt target. Binaryen's wasm-opt is built with exceptions enabled
  +  # and links the toolchain libc++, whose bundled libcxxabi exception symbols
  +  # collide with the no-exceptions stubs in the engine's libcxxabi. The
  +  # prebuilt Dart SDK already ships a wasm-opt binary for platforms that have
  +  # one, so this only affects from-source builds.
  +  if not gn_args.get('flutter_prebuilt_dart_sdk'):
  +    gn_args['dart_include_wasm_opt'] = False
  +
     if args.build_glfw_shell is not None:
       gn_args['build_glfw_shell'] = args.build_glfw_shell

  I had AI's help on this one, and here is the AI summary:

  • riscv64 has no prebuilt Dart SDK (flutter/prebuilts/ only has linux-x64 and linux-arm64;
    can_use_prebuilt_dart returns False for linux_cpu=riscv64). So flutter_prebuilt_dart_sdk
    stays false and the Dart SDK is built from source.
  • Building the SDK from source builds wasm-opt (Binaryen), which is compiled with
    //build/config/compiler:enable_exceptions.
  • The engine's own libcxxabi
    (flutter/build/secondary/flutter/third_party/libcxxabi/BUILD.gn) compiles
    cxa_noexception.cpp on Linux — stubs that define __cxa_current_primary_exception,
    __setExceptionClass, etc. as no-op/terminate.
  • On Linux the build does not pass -nostdlib++ (build/config/compiler/BUILD.gn:644 only adds
    it if (!is_linux)), so the clang driver auto-links the toolchain's libc++.a. The riscv64
    buildtools/.../clang/lib/riscv64-unknown-linux-gnu/libc++.a bundles libcxxabi's
    cxa_exception.cpp.o (the real exception implementations).
  • wasm-opt uses exceptions → the linker resolves __cxa_throw etc. by pulling cxa_exception.o
    out of the toolchain libc++.a. That object also defines
    __cxa_current_primary_exception/__setExceptionClass/… → duplicate symbols with the
    already-linked libcxxabi.cxa_noexception.o.

After those two changes:

$ et build -c ci/linux_debug_riscv64
[2026-08-12T11:26:47.574][ci/linux_debug_riscv64: GN]: OK
[2026-08-12T11:26:56.767][ci/linux_debug_riscv64: ninja]: 100.0% (5/5) ACTION //flutter/build/archives:artifacts(//build/toolchain/linux:clang_riscv64)
[2026-08-12T11:26:56.783][ci/linux_debug_riscv64: ninja]: OK

I am not sure how to proceed here. I believe the second issue should be patched here, and I will add a commit on the PR for that patch (unless you advise me not to). It seems to me that it makes sense to disable that feature for every "from-source" builds, as it will break every from-source build otherwise, AFAIU.

For the first issue, it gets a bit more tricky. The right solution would be to send the fix to Debian so that it gets into Trixie. Current Trixie version for that package is 2.56.2-1+deb13u1, and the fix is available starting from upstream version 2.59.0. I'm not completely familiar with how patches are sent to non-devel Debian versions, but I believe that this is the cleanest way.

Another issue that we would have, though, is that Bullseye might be too old to patch (it is oldoldstable).

The only other way IMO would be a script here that applies this patch directly.

Thoughts? Does everything makes sense? Do we want to take in the PR without the Debian fix, so that then we can build by manually patching, or do we want to wait until everything is ready first? Or maybe add another trixie-specific workaround that applies the patch, while hoping that Debian takes it?

The Debian route seems convoluted, and I have confirmed that there will be no way to fix bullseye. I have added a patch function in the sysroot setup, I believe that this is the cleaner fix, and it will also allow updating sysroots to Trixie for other arches desktop builds, so I believe this is a win-win?

With this patch, the engine build succeeds 😃
If you are willing to take all 3 commits, we will officially be able to cross-build the engine for riscv64