Hey <@U8NMFHUGJ> are there plans to update <cklib>...
# touchlab-tools
m
Hey @kpgalligan are there plans to update cklib? We started using it when we were working with the Touchlab team to help jump-start our SDK. I've noticed the note,
The main Kotlin project has changed how locally embedded C-like code is included in libraries. Use this project if you'd like, but outside of private projects we won't really be supporting it much.
And was wondering what the alternative is. Where should we be looking? It appears to work in Kotlin 1.8, but we're having test failures in native wrapper code that didn't previously fail pre-updated. I am unsure of whether the issue is caused by Kotlin native changes or cklib's compatibility with 1.8.
r
We don't have definite update plans right now. It's no longer part of the Kermit/CrashKiOS stack which was our main use-case internally. Kevin can probably speak better than I can to what good alternatives are, but he's on vacation this week so I'll try to draw his attention here when he gets back.
m
Thanks @russhwolf, I appreciate the response ­čÖé Interested in getting more information, or just a suggestion at an alternative we can use if cklib is no longer supported.
k
On vacation. Shakey wifi. We don't support cklib because the projects that need it are rather complex, generally speaking, so it's drifting towards more of a "paid support" situation. Cklib has a problem with 1.7.x and some watch architectures, but we never used those. 1.8 seems ok. This is the only public use of cklib at this point: https://github.com/cashapp/zipline/.
What errors?
m
Hey Kevin, no need to respond on your vacation, we'll survive ­čÖé For when you're back, the errors are actually not hard errors, but soft ones. Basically, a number of the functions we're interfacing with from the C code no longer return the expected values (they just return 0 or empty string). We are wrapping generated FlatBuffers C code (
flatcc
) in a common interface and the tests no longer pass on native. The switch is as clear as day due to
1.7.10
-->
1.7.20
. We're already on the
experimental
memory model in
1.7.10
so the change to
1.7.20
shouldn't have done anything big. And yet
And as far as platforms we've observed this on at least
macosArm64
and
linuxX64
and haven't tried other platforms.