riscv64: duplicate __cxa* symbols linking wasm-opt (vendored libcxxabi vs toolchain libc++.a) #24

Activity

1. jwinarske commented on Sep 2, 2026

   

   jwinarske

   on Sep 2, 2026

   ContributorAuthor

   More actions

   Correction to the above: the per-target lib directory is not the difference. All
   four targets ship one and all four contain libc++.a:

   x86_64-unknown-linux-gnu          libc++.a
   aarch64-unknown-linux-gnu         libc++.a
   armv7-unknown-linux-gnueabihf     libc++.a
   riscv64-unknown-linux-gnu         libc++.a
   

   The actual difference is that riscv64 is the only build that compiles binaryen at
   all:

   arch	binaryen objects	ninja targets
   x86_64	6	9255
   armv7hf	6	7585
   riscv64	282	14380

   x86_64 and armv7hf never link wasm-opt; there is no mention of it in either
   log. So this is not "riscv64 links libc++ differently", it is "riscv64 builds a
   tool the other targets do not build", and that tool is what hits the collision.

   wasm-opt is only reachable from dart2wasm_benchmark in
   third_party/dart/BUILD.gn, which nothing in an embedder build should want. The
   gn invocations in the three workflows are identical apart from the arch
   variables, so whatever pulls it in is inside the engine's own gn logic keyed on
   target_cpu.

   Open question, and the command that answers it:

   gn refs out/linux_debug_riscv64 //flutter/third_party/dart/third_party/binaryen:wasm-opt --all
   

   I could not run it: the riscv64 out directory is gone and the workspace is busy
   with another build.

   That reframes the fix. -nostdlib++ would get the link to pass, but if wasm-opt
   has no business being built for the target then not building it is the better
   answer and drops ~7000 ninja targets with it.
2. jwinarske commented on Sep 2, 2026

   

   jwinarske

   on Sep 2, 2026

   ContributorAuthor

   More actions

   Traced it to upstream flutter/tools/gn, which already knows this target does
   not build:

     if args.prebuilt_dart_sdk:
       if can_use_prebuilt_dart(args):
         gn_args['flutter_prebuilt_dart_sdk'] = True
         ...
       elif is_host_build(args):
         print('Tried to download prebuilt Dart SDK but ...')
     elif is_host_build(args):
       # If we are building the dart sdk in-tree, exclude the wasm-opt target, as
       # it doesn't build properly with our gn configuration.
       gn_args['dart_include_wasm_opt'] = False

   "It doesn't build properly with our gn configuration" is their comment, not
   mine. The exclusion is only ever applied when is_host_build() is true, and
   that is:

     if args.target_os is None:                                   return True
     if args.target_os == 'linux' and args.linux_cpu == 'arm64':  return True
     if args.target_os == 'mac':                                  return True
     return False

   linux/riscv64 is none of those, so the exclusion never fires for us and
   dart_include_wasm_opt keeps its default of is_clang || !is_win, i.e. true.
   sdk/BUILD.gn then pulls :copy_wasm_opt into create_most_sdk and wasm-opt
   gets built with the custom toolchain, where it hits the libc++ collision.

   Why x86_64 and arm64 never see it: flutter/prebuilts/ ships linux-x64 and
   linux-arm64 only, so can_use_prebuilt_dart() is true for both and no Dart SDK
   is built in-tree at all.

   One thing I cannot account for yet. armv7hf has no prebuilt either, so by the
   same reading it should build the SDK and hit this too, and it does not: 282
   binaryen objects on riscv64 against 6 on armv7hf, and those 6 are the gclient
   checkout, not compilation. So the model above is incomplete somewhere. Comparing
   out/linux_debug_arm/args.gn with out/linux_debug_riscv64/args.gn would settle
   it and is cheaper than my guessing further.

   Fix direction: tools/gn has no --gn-args passthrough, so this wants a patch
   alongside 0003-gn-riscv32-and-riscv64.patch, setting
   dart_include_wasm_opt = False when the SDK is built in-tree rather than only
   for host builds. That follows the upstream comment's intent and drops roughly
   7000 ninja targets from the riscv64 build as a side effect.
3. jwinarske commented on Sep 2, 2026

   

   jwinarske

   on Sep 2, 2026

   ContributorAuthor

   More actions

   Following up on the gap I flagged: it is real, and it breaks the model above.

   I had only looked at the 2026-08-26 armv7hf log, which died at the first release
   step and so only ever ran Build Debug. The complete armv7hf run from today
   (all three ninja invocations, 34777 log lines) still shows zero wasm-opt:

   binaryen lines: 6      (gclient checkout only, no compilation)
   wasm-opt lines: 0
   ninja targets:  7412 / 7498 / 7585      vs riscv64's 14380
   

   So armv7hf genuinely never builds it, and that contradicts the reading above.
   flutter_prebuilt_dart_sdk defaults to false (flutter/common/config.gni:18)
   and can_use_prebuilt_dart() is false for linux_cpu=arm just as it is for
   riscv64, so by that path armv7hf should build the SDK in-tree and hit this too.
   It does not.

   Confirmed separately from out/linux_debug_arm64/args.gn on the runner:

   flutter_prebuilt_dart_sdk = true
   dart_sdk_output = "built-dart-sdk"
   

   and no wasm-opt binary in that out directory, so the prebuilt half of the
   explanation holds for arm64 and x86_64. It is the armv7hf-versus-riscv64 half
   that is unexplained.

   The gn flags in the two workflows are identical apart from linux_cpu,
   target_triple and target_sysroot, so whatever diverges is keyed on one of
   those inside gn. Diffing out/linux_debug_arm/args.gn against
   out/linux_debug_riscv64/args.gn is still the thing that answers it. I have not
   been able to: the two builds land on different runners and neither out directory
   survives.

   Leaving the dart_include_wasm_opt finding above as accurate about why the
   link fails -- it is what puts wasm-opt in the riscv64 graph -- but the reason
   armv7hf escapes is not yet established, so anyone patching should get that diff
   first rather than trusting my account of the gating.
4. jwinarske commented on Sep 3, 2026

   

   jwinarske

   on Sep 3, 2026

   ContributorAuthor

   More actions

   Fixed by #26: the riscv64 workflow passes --gn-args=dart_include_wasm_opt=false,
   the same thing meta-flutter's flutter-engine recipe has done since it hit this.

   riscv64 builds and publishes again on both current revisions, for the first time
   since 3.44.2 in June:

   version	srcrev	artifacts
   3.47.1	5d531788	15 -- arm64 4, armv7hf 4, x86_64 4, riscv64 3
   3.47.2	a804b261	15 -- arm64 4, armv7hf 4, x86_64 4, riscv64 3

   riscv64 publishes three modes rather than four; its workflow has no
   Build Debug Unoptimized step.

   What is left unexplained

   armv7hf has no prebuilt Dart SDK either, so it should build the SDK in-tree and
   hit this the same way. It does not, and I could not work out why.

   Ruled out along the way:

   • the gn args are identical for the two, bar target_cpu, dart_target_arch,
     arm_float_abi, the sysroot and the triple. I ran the real to_gn_args() from
     tools/gn against both argument sets rather than eyeballing it
   • can_use_prebuilt_dart() and is_host_build() are both false for both
   • dart_include_wasm_opt has exactly three references in the tree
     (sdk/BUILD.gn:38, sdk/BUILD.gn:816, tools/gn:714) and none of them keys
     off the architecture
   • create_most_sdk gates copy_wasm_opt only on ia32/x86, which arm passes

   The one arch-keyed difference I did find is sdk/BUILD.gn:832, which excludes
   arm from the cross gen_snapshot deps. That accounts for the build-size gap
   (444 gen_snapshot lines on riscv64 against 304 on armv7hf) but not for wasm-opt.

   Answering it properly needs gn desc or gn path on a real generated build
   directory for each arch, which I could not produce: the two builds land on
   different runners and neither out directory survives. Closing anyway, since the
   defect is fixed and shipped -- worth reopening only if armv7hf ever starts
   building wasm-opt too.
5. jwinarske

   closed this as completedon Sep 3, 2026