I'm facing an issue with KMMBridge (with SPM) work...

# touchlab-tools

[Matija Sokol]

I'm facing an issue with KMMBridge (with SPM) workflow after migrating to Kotlin 2.x.x.

Currently, I'm using Kotlin 2.1.0 and KMMBridge 1.1.1
My KMMBridge-iOS-publish.yml is mostly the same as one from docs (differs in some config stuff), and it breaks at Build Main step (when executing :shared:linkReleaseFrameworkIosArm64 gradle task) with stacktrace:

LLVM module dump: /var/folders/z_/gfjxrj2x0dxdn31ddjjfx_kw0000gn/T/kotlin_native_llvm_module_dump5913300533319819165.ll
	at org.jetbrains.kotlin.backend.konan.llvm.VerifyModuleKt.throwModuleVerificationError(VerifyModule.kt:38)
	at org.jetbrains.kotlin.backend.konan.llvm.VerifyModuleKt.verifyModule(VerifyModule.kt:21)
	at org.jetbrains.kotlin.backend.konan.llvm.VerifyModuleKt.verifyModule$default(VerifyModule.kt:8)
...

Also, I'm getting warning about some Arrow and Moko stuff which I think aren't relevant since I'm able to run ./gradlew spmDevBuild and run my iOS app locally with generated framework. Arrow (2.0.0) and Moko (0.24.4) are updated to latest stable version which are confirmed to be compatible with Kotlin 2.1.0.

I'm pasting a warning stacktrace so you can see if this is relevant to this issue:

w: Interop library /Users/*/.gradle/caches/modules-2/files-2.1/dev.icerock.moko/resources-iosarm64/0.24.4/1b3561e0fb8ff6dc4d2c82d388941127f49602f0/resources-cinterop-bundleSearcher can't be exported with -Xexport-library
w: Cannot infer a bundle ID from packages of source files and exported dependencies, use the bundle name instead: Shared. Please specify the bundle ID explicitly using the -Xbinary=bundleId=<id> compiler flag.
e: Compilation failed: Invalid LLVM module
Verification errors:
    Instruction does not dominate all uses!
      %47 = call ptr @AllocInstance(ptr noundef @"kclass:arrow.core.raise.DefaultRaise", ptr noundef %6) #14, !dbg !184364
      %139 = call zeroext i1 @"kfun:arrow.core.raise.DefaultRaise#complete(){}kotlin.Boolean"(ptr %47), !dbg !184412
    Instruction does not dominate all uses!
      %47 = call ptr @AllocInstance(ptr noundef @"kclass:arrow.core.raise.DefaultRaise", ptr noundef %6) #14, !dbg !184364
      %141 = call zeroext i1 @"kfun:arrow.core.raise.DefaultRaise#complete(){}kotlin.Boolean"(ptr %47), !dbg !184417
    Instruction does not dominate all uses!
      %47 = call ptr @AllocInstance(ptr noundef @"kclass:arrow.core.raise.DefaultRaise", ptr noundef %6) #14, !dbg !184364
      %142 = call ptr @"kfun:arrow.core.raise#raisedOrRethrow__at__kotlin.coroutines.cancellation.CancellationException(arrow.core.raise.DefaultRaise){0\C2\A7<kotlin.Any?>}0:0"(ptr %131, ptr %47, ptr %11), !dbg !184418

[kpgalligan]

KMMBridge essentially just runs the Kotlin build tasks necessary for your publication, depending on your configuration. It doesn't change anything significant that's related to builds. I wouldn't say for sure it's not changing something that's causing an issue, but unlikely. I'd start by running :shared:linkReleaseFrameworkIosArm64

[Matija Sokol]

When I run ./gradlew :shared:linkReleaseFrameworkIosArm64 locally I get same error as mention above (LLVM module dump...). Does this means that the task is broken or my app/configuration is incorrect?

[kpgalligan]

Yes. Locally, KMMBridge skips publishing-related configuration if publishing is not enabled with -PENABLE_PUBLISHING=true. For local dev, KMMBridge runs configureXcFramework and configureLocalDev. configureXcFramework creates config that adds the XCFramework build config, which shouldn't impact anything related to the link tasks (what it does happens later), and configureLocalDev creates spmDevBuild, which is also after the link tasks.

[kpgalligan]

First, I'd run the simulator builds but with release instead of debug, to see if it's a release vs debug thing, then if not I'd try to figure out if it's a simulator vs device build thing.

[kpgalligan]

So, linkReleaseFrameworkIosSimulatorArm64 would build a release build for the simulator. See if that works. Sometimes release builds do something different that causes an issue. For a debug device build, linkDebugFrameworkIosArm64. Sometimes simulator and release builds differ.

[kpgalligan]

The actual failure looks like something deeper, though. An LLVM thing. That's probably a release vs debug issue.

[kpgalligan]

The 2.0.0 of Arrow worries me. I assume there were a lot of changes, and it's only been out for a few days. That significantly raises the likelihood of running into weird things. That, and Kotlin 2.1.0 is very recent as well.

[Matija Sokol]

Just tested your proposal, here are results:
linkReleaseFrameworkIosArm64 ❌
linkReleaseFrameworkIosSimulatorArm64 ❌

linkDebugFrameworkIosArm64 ✅
linkDebugFrameworkIosSimulatorArm64 ✅

This also works:
assembleRelease ✅

Both of ❌ have same error (LLVM module dump...)
So, actually it seems that problem is with release type. Can this happen because of obfuscation/minification? Or something else?

[kpgalligan]

I assume it's something the Kotlin team has to look at. I've seen similar things on occasion, but they're pretty low level.