Hi there, not sure if this is for mp, ios or this channel, so please bear with me: stuck on a issue where I have added a native IOS target to an existing mp multi-module project. Simply added this to gradle.build:

iosX64("ios") {
    binaries {
        framework()
    }
}

plus sourcesets, and implemented a few expected types. All compilation tasks run successfully but the

linkReleaseFrameworkIos

always fails with a Java assertion error somewhere in the native compiler with zero hints to actual cause. Link debug framework succeeds for iosX64 but will likewise also fail for iosArm64. I deliberately chose one of the stand-alone modules as to not also deal with dependency issues. Any pointer to how I should approach this problem is greatly appreciated 🙏 Searching the docs didn’t yield much in terms of debugging compilations issues. Thanks. Slack Conversation

It could help if you showed the stacktrace from the error?

Absolutely @Luis, and thanks. Kotlin version is 1.5.21. I cannot share the build gradle unfortunately, but it’s a multi-module project with all things multiplatform being applied in the root build.gradle. I’m trying to build a single sub-project with no dependencies to any of the other projects. Thanks for pointing out that I don’t need the

binaries.framework

- I had been playing around with setting the baseName and left it there.

Yeh, sorry @Lars Toft Jacobsen I can’t see what the issue could be without peeking the build.gradle… I do know that on my project I have the iOS declaration depending on a

SDK_NAME

variable, so I can build stuff for the iOS simulator

val iosTarget: (String, KotlinNativeTarget.() -> Unit) -> KotlinNativeTarget = when {
    System.getenv("SDK_NAME")?.startsWith("iphoneos") == true -> ::iosArm64
    else -> ::iosX64
}

iosTarget("ios") {}

Maybe you could have an issue with that?

Hmm. Ok I gathered as much that the emulator target was my best bet, and it also proved to be the one getting furthest. There's no difference afaics between using the target directly as I do vs setting it via some logic that reads an ENV. I was hoping someone could point to how I could crank out more information from the compiler in order to uncover the actual cause of the linker error or hints as to why the debug linking would succeed when the release one fails.