I’m attempting to upgrade a project to Kotlin 1.9.20 and I’m getting a surprising failure pulling in...

# kotlin-native

[jessewilson]

I’m attempting to upgrade a project to Kotlin 1.9.20 and I’m getting a surprising failure pulling in a dependency that uses cinterop.

> Task :treehouse:apis:ui:compileKotlinIosSimulatorArm64 FAILED
w: skipping /Users/jwilson/.gradle/caches/modules-2/files-2.1/app.cash.zipline/zipline-iossimulatorarm64/1.5.0/9c51551230e28885097f21691ddcd12999fb13fb/zipline-cinterop-quickjs.klib. The library versions don't match. Expected 'unspecified', found '1.5.0'
e: Could not find "app.cash.zipline:zipline-cinterop-quickjs" in [/Volumes/Development/cash-treehouse, /Users/jwilson/.konan/klib, /Users/jwilson/.konan/kotlin-native-prebuilt-macos-aarch64-1.9.20/klib/common, /Users/jwilson/.konan/kotlin-native-prebuilt-macos-aarch64-1.9.20/klib/platform/ios_simulator_arm64]

Why is it expecting 'unspecified’ ? Any tips on fixing this?

[jessewilson]

Screenshot 2023-11-03 at 2.02.38 PM.png

[jessewilson]

Looks like some of the packaging of the main native artifact specifies a version of this thing, and no versions elsewhere

[jessewilson]

I could probably hack this by changing my Zipline build to not include that version in that manifest

[jessewilson]

Okay, more info . . . I’ve got a few different libraries here:

zipline : regular klib
zipline-cinterop-quickjs : cinterop klib
redwood-treehouse : depends on zipline-cinterop-quickjs

[jessewilson]

My redwood-treehouse library depends on zipline-cinterop-quickjs with version unspecified

[jessewilson]

My zipline library depends on zipline-cinterop-quickjs with version 1.5.0

[jessewilson]

I suspect the problem might be that my third library depends on both, and sees two different versions, unspecified and 1.5.0

[jessewilson]

Yeah I think that’s it.

This line is in the zipline library klib’s default/manifest built with 1.9.10:

dependency_version_app.cash.zipline\:zipline-cinterop-quickjs=unspecified

This line is in the zipline library’s klib’s default/manifest built with 1.9.20:

dependency_version_app.cash.zipline\:zipline-cinterop-quickjs=1.5.0

I think the 1.5.0 is both more correct and also the source of my current pain

[jessewilson]

Now . . . I wonder if I can hack my build to work like 1.9.10 did so my downstream projects don’t explode as they are

[jessewilson]

Okay, more stuff. The library_version inside the klib’s own module is unspecified when it’s built by Kotlin 1.9.10, and it’s the Gradle version (1.5.0) when it’s built by Kotlin 1.9.20

library_version=1.5.0

When zipline depends on zipline-cinterop-quickjs, it reads the version from the zipline-cinterop-quickjs klib’s own default/manifest file

[jessewilson]

And so in order to suppress the version, I have to prevent it from being emitted in the default/manifest file

[jessewilson]

I think I found the place where this was introduced!
https://github.com/JetBrains/kotlin/commit/2719dd188f00fab15988a7be99c5424eae5cb4db#diff-cd8be4294045978eb035e62e5[…]9bb67327370aed9538ce0ecf0eL1138

[jessewilson]

https://youtrack.jetbrains.com/issue/KT-58315

[jessewilson]

And I found a tracking bug: https://youtrack.jetbrains.com/issue/KT-62515

[Jeff Lockhart]

I just ran into this same error after updating atomicfu to 0.23.0:

> Task :couchbase-lite:cinteropCouchbaseLiteIosSimulatorArm64 FAILED
w: skipping /Users/jeff/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlinx/atomicfu-iossimulatorarm64/0.23.0/10b6de0b94aceaca2bf723ec1cdedc261232cfd5/atomicfu-cinterop-interop.klib. The library versions don't match. Expected 'unspecified', found '0.23.0'
e: Could not find "org.jetbrains.kotlinx:atomicfu-cinterop-interop" in [/Users/jeff/Documents/GitHub/kotbase/couchbase-lite, /Users/jeff/.konan/klib, /Users/jeff/.konan/kotlin-native-prebuilt-macos-x86_64-1.9.20/klib/common, /Users/jeff/.konan/kotlin-native-prebuilt-macos-x86_64-1.9.20/klib/platform/ios_simulator_arm64]

If I understand the cause correctly, this is because another dependency (kotlinx-coroutines) depends on an older 0.21.0 version, which is published with cinterop version "unspecified", which conflicts with the newer version, published with cinterop version 0.23.0 because it was built with Kotlin 1.9.20?

Would your workaround need to be applied to the upstream atomicfu build? Is there no known workaround for my own build?

[jessewilson]

Yeah I think you need the workaround in atomicfu. This bug sucks

[Jeff Lockhart]

Thanks for your research figuring out these details!

[Jeff Lockhart]

https://github.com/Kotlin/kotlinx-atomicfu/issues/365

[dmitriy.dolovov]

Hello. This is a really unexpected behavior in the compiler. We are elaborating now on how to fix it.

[Alex Acosta]

I am trying the workaround provided but it is not working for me, is the CInteropProcess the correct task type?

[jessewilson]

this is our workaround in Zipline:
https://github.com/cashapp/zipline/blob/trunk/build.gradle.kts#L242-L251

[Alex Acosta]

Thanks so much, still, I am trying my best to figure out why is not working for me but still no luck

[Jeff Lockhart]

Alex, if this error is caused by an upstream dependency, the workaround is needed in that code to publish a working artifact.

[Alex Acosta]

Yeah, absolutely, I am placing this workaround in the same project where the module is and directly being used as a pod by an XCode project.

[dmitriy.dolovov]

We are almost ready with the fix for KT-62515. The fix will land in 1.9.21 (to be released the next week) and in 2.0.0-Beta-2 (no exact date yet). Please wait for a while with upgrading to 1.9.20 till the release of 1.9.21.

As for atomicfu, a new version is going to be released right after 1.9.21: https://github.com/Kotlin/kotlinx-atomicfu/issues/365#issuecomment-1815877256

[dmitriy.dolovov]

We are almost ready with the fix for KT-62515. The fix will land in 1.9.21 (to be released the next week) and in 2.0.0-Beta-2 (no exact date yet). Please wait for a while with upgrading to 1.9.20 till the release of 1.9.21.

Hello. I would like to say that Kotlin 1.9.21 just has been released.