From 3ab14f5a934f9989e1a1d77cc6e7257abb75cfc4 Mon Sep 17 00:00:00 2001 From: Alain Brenzikofer Date: Thu, 6 Aug 2026 08:30:35 +0200 Subject: [PATCH] plan update --- plans/2026-08-05-eth-crypto-bindings.md | 42 ++++++++++++++++++++++--- 1 file changed, 38 insertions(+), 4 deletions(-) diff --git a/plans/2026-08-05-eth-crypto-bindings.md b/plans/2026-08-05-eth-crypto-bindings.md index a87a52fd3..218610202 100644 --- a/plans/2026-08-05-eth-crypto-bindings.md +++ b/plans/2026-08-05-eth-crypto-bindings.md @@ -212,10 +212,44 @@ there only force `packages.simplexmq.components.library.libs` (external libraries, i.e. openssl for `extra-libraries: crypto`) and flags. Vendored `c-sources` need no nix entry, which is why blst and libbbs have none either. -**Cross-compilation is unproven.** This has been built and tested on x86-64 -Linux only. iOS arm64 and the simulator, the Android ABIs, and the Windows -desktop build all still need proving, and that is where the remaining risk in -this workstream sits. +### Cross-compilation status + +Verified by building simplex-chat through its flake: + +| Target | Result | +|---|---| +| `x86_64-linux` (native, nix) | compiles and links | +| `aarch64-android` | **compiles and links** into the final shared object | +| `armv7a-android` | libsecp256k1 compiles; final link not reached (see below) | +| `x86_64-windows` (mingw) | blocked before our code — see below | +| `aarch64-darwin-ios` | not yet run (needs a darwin host) | + +`aarch64-android` is the meaningful pass: it proves the C both cross-compiles +and links into the artifact the app actually ships. + +`armv7a-android` gets far enough to prove the 32-bit path compiles — that is, +libsecp256k1's `SECP256K1_WIDEMUL_INT64` fallback builds under the NDK — but the +build then dies in simplex-chat's own `Simplex.Chat.Operators`, on the +`$(embedFile "PRIVACY.md")` splice. Cross-compiled Template Haskell runs the +splice on the target via `iserv-proxy` under `qemu-arm`, and that interpreter +fails to resolve `realpath` out of `libHSdirectory` and segfaults. It is +unrelated to this work: none of these modules use Template Haskell, and +simplexmq (which does) builds for armv7a fine. So 32-bit *linking* remains +unproven, though there is no plausible mechanism by which it would fail given +aarch64 links and the 32-bit objects compile. + +`x86_64-windows` fails while bootstrapping the mingw cross-GHC, long before any +of our code is considered: haskell.nix applies +`ghc-9.6-fix-code-symbol-jumps.patch` to `rts/linker/PEi386.c` twice from the +same store path, and the second application aborts. That is a duplicate entry in +the patch list of the pinned haskell.nix branch +(`github:input-output-hk/haskell.nix/armv7a`), not something this change can +influence. + +Both gaps can be closed without GHC by compiling the three C files with the +cross toolchain directly and linking a program that calls into both the core and +the recovery module — that isolates the C question from the Haskell build +entirely. ## Tests