oss-swift-package-swift-sdk-for-android failed: error: could not find module '_Builtin_float' for target 'x86_64-unknown-linux-android'

[al45tair]

The Android SDK build is failing with

<unknown>:0: error: could not find module '_Builtin_float' for target 'x86_64-unknown-linux-android'; found: aarch64-unknown-linux-android, at: /home/build-user/build/swift-project/Ninja-Release/swift-linux-x86_64/lib/swift/android/_Builtin_float.swiftmodule/x86_64-unknown-linux-android

See https://ci.swift.org/job/oss-swift-package-swift-sdk-for-android/52

rdar://163791713

[shahmishal]

cc: @swiftlang/android-workgroup

[marcprux]

I think we were hoping that #507 would fix that, but apparently not…

[finagolfin]

Tough for that pull to go back in time before it was merged, 😉 this is the first CI run with it, let's see.

[marcprux]

Note that only half of the most recent 7 failures are due to this flaky occurrence (sometimes it fails for x86_64-unknown-linux-android, other times for armv7-unknown-linux-android).

The other half are due to a new test failure:

03:32:15  /source/swift-project/swift/test/SILOptimizer/pack_specialization.swift:6:11: error: CHECK: expected string not found in input
03:32:15  // CHECK: define {{.*}} { i64, i64, ptr, double } @"$s19pack_specialization8copyPack2xsxxQp_txxQp_tRvzlFSi_SSSdQP_Tg5Tf8xx_n"(i64 %0, i64 %1, ptr %2, double %3)

[finagolfin]

The other half are due to a new test failure

I reported the new 32-bit-only test failure to its author over the weekend, he graciously submitted a fix today, should be merged by this afternoon.

[finagolfin]

Hmm, #507 didn't work, likely because I tried to remove a build directory through a symlink, will try another approach and update the script.

[marcprux]

The test case failure just got merged (swiftlang/swift#85279 (comment)), hopefully we'll get a successful build soon (modulo flakes).

[finagolfin]

Hmm, I'm stumped by why another flake still happened after the workaround pull #507 was merged, as I checked and my pull is deleting the Android-specific portion of the Swift resource directory through the symlink after each arch is built. It is possible that the CMake reconfigure after the stdlib for each arch is built and deleted isn't working right or some other file like that is sticking around somehow.

The good news is the trunk CI passed again, after Aidan updated his new test for 32-bit platforms also. I will look into this underlying issue more in the coming week, let's see how many flakes we get from now on.