https://kotlinlang.org logo
Channels
Powered by
#kotlin-native
Title
# kotlin-native
j

jessewilson

11/03/2023, 5:04 PM
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.
Copy code
> 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?
Screenshot 2023-11-03 at 2.02.38 PM.png
Looks like some of the packaging of the main native artifact specifies a version of this thing, and no versions elsewhere
I could probably hack this by changing my Zipline build to not include that version in that manifest
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
My 
redwood-treehouse
library depends on 
zipline-cinterop-quickjs
with version 
unspecified
My 
zipline
library depends on 
zipline-cinterop-quickjs
with version 
1.5.0
I suspect the problem might be that my third library depends on both, and sees two different versions, 
unspecified
and 
1.5.0
Yeah I think that’s it. This line is in the 
zipline
library klib’s 
default/manifest
built with 1.9.10:
Copy code
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:
Copy code
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
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
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
Copy code
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
And so in order to suppress the version, I have to prevent it from being emitted in the 
default/manifest
file
👀 1
j

Jeff Lockhart

11/16/2023, 5:53 AM
I just ran into this same error after updating atomicfu to 0.23.0:
Copy code
> 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?
j

jessewilson

11/16/2023, 5:54 AM
Yeah I think you need the workaround in atomicfu. This bug sucks
💯 1
j

Jeff Lockhart

11/16/2023, 5:57 AM
Thanks for your research figuring out these details!
d

dmitriy.dolovov

11/16/2023, 1:38 PM
Hello. This is a really unexpected behavior in the compiler. We are elaborating now on how to fix it.
thank you color 2
a

Alex Acosta

11/16/2023, 6:24 PM
I am trying the workaround provided but it is not working for me, is the 
CInteropProcess
the correct task type?
j

jessewilson

11/16/2023, 6:36 PM
a

Alex Acosta

11/16/2023, 6:50 PM
Thanks so much, still, I am trying my best to figure out why is not working for me but still no luck
j

Jeff Lockhart

11/16/2023, 7:28 PM
Alex, if this error is caused by an upstream dependency, the workaround is needed in that code to publish a working artifact.
a

Alex Acosta

11/16/2023, 9:04 PM
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.
d

dmitriy.dolovov

11/17/2023, 3:36 PM
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
thank you color 2
🎉 3
🦜 1
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.
K 2
thank you color 1
🐕 1
28 Views
Powered by