From 28c2509c8050d97dc4b22cf738cc2942607fa75c Mon Sep 17 00:00:00 2001
From: Ken Tominaga <ken.for.develop@gmail.com>
Date: Sun, 26 Apr 2026 02:21:51 -0700
Subject: [PATCH] [android-sdk] strip cross-arch swiftmodule leakage from
 per-arch overlays

The Swift stdlib and sdk-overlay install steps run from a shared
SWIFT_BUILD_ROOT across all cross-compile-host iterations of build.sh.
Each iteration's install pulls in .swiftinterface / .swiftmodule files
from every host that built before it, leaving non-monotonic per-arch
overlays in the bundle:

  lib/swift-aarch64/android/Android.swiftmodule/   - aarch64 only
  lib/swift-x86_64/android/Android.swiftmodule/    - aarch64 + x86_64
  lib/swift-armv7/android/Android.swiftmodule/     - all three

Foundation, Dispatch, XCTest, and swift-testing are built per-arch via
separate CMake invocations and are correctly partitioned, so the leak
is confined to the 16 stdlib + sdk-overlay swiftmodule dirs (Swift,
Android, _Concurrency, Cxx, CxxStdlib, _Builtin_float, _math,
_RegexParser, _StringProcessing, _Volatile, _Differentiation,
Distributed, Observation, RegexBuilder, SwiftOnoneSupport,
Synchronization).

The asymmetry interacts badly with SwiftPM's targetTriples lookup:
when SwiftPM picks the wrong swiftResourcesPath for the requested
--triple, the wrong-arch .swiftinterface load succeeds because of the
leaked files, and the failure surfaces one step later as a Clang
modulemap miss ("missing required module 'SwiftAndroid'") instead of
the cleaner "could not find module 'Foundation' for target ...".

Strip leaked entries during the bundling stage, after the per-arch
rename and before the rsync into swift_res_root, so each
lib/swift{,_static}-<arch>/android/*.swiftmodule/ contains only this
arch's triple - matching the layout already produced by Foundation
and friends.
---
 swift-ci/sdks/android/scripts/build.sh | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/swift-ci/sdks/android/scripts/build.sh b/swift-ci/sdks/android/scripts/build.sh
index af6d7e1a..8f8e0b07 100755
--- a/swift-ci/sdks/android/scripts/build.sh
+++ b/swift-ci/sdks/android/scripts/build.sh
@@ -670,6 +670,30 @@ for arch in $archs; do
         mv lib/lib*.a lib/swift_static-$arch/android
 
         ln -sv ../swift/clang lib/swift_static-$arch/clang
+
+        # The Swift stdlib + sdk-overlay install steps run from a shared
+        # SWIFT_BUILD_ROOT across cross-compile-host iterations and pull
+        # .swiftinterface / .swiftmodule files from every host that built
+        # before this one, leaving non-monotonic per-arch overlays
+        # (e.g. lib/swift-armv7/android/Android.swiftmodule/ ends up with
+        # aarch64-* and x86_64-* triple files alongside armv7-*). When
+        # SwiftPM's targetTriples lookup picks the wrong swiftResourcesPath,
+        # the wrong-arch .swiftinterface load succeeds and the failure
+        # surfaces one step later as a Clang modulemap miss ("missing
+        # required module 'SwiftAndroid'") instead of the cleaner
+        # "could not find module 'Foundation' for target ...". Strip the
+        # leaked cross-arch entries so each lib/swift{,_static}-<arch>/
+        # android/*.swiftmodule/ contains only this arch's triple, matching
+        # the per-arch layout already produced by Foundation, Dispatch,
+        # XCTest, and swift-testing.
+        keep_triple_prefix="${arch}-unknown-linux-android."
+        for swiftmod_root in lib/swift-$arch/android lib/swift_static-$arch/android; do
+            for swiftmod_dir in ${swiftmod_root}/*.swiftmodule; do
+                [ -d "${swiftmod_dir}" ] || continue
+                find "${swiftmod_dir}" -mindepth 1 -maxdepth 1 -type f \
+                    ! -name "${keep_triple_prefix}*" -delete
+            done
+        done
     quiet_popd
 
     # now sync the massaged sdk_root into the swift_res_root