https://kotlinlang.org logo
Join Slack
Powered by
What is the recommended way to link against (and/o...
# kotlin-native
v
What is the recommended way to link against (and/or provide) other native libraries for a kotlin native project? I'm currently experimenting a bit with sqlite3 using SqlDelight (which uses SQLiter under the hood) and it quickly becomes linker hell because of mismatched libc versions. In the end I kind of get it working after recompiling sqlite3 using the konan gcc
Copy code
export CC=<konan-gcc>
export LDFLAGS=-L<konan-lib-folder>
./configure --prefix=/tmp/somelibfolder
and linking that in my final output binary.
k
You may want to ask this in #squarelibraries. The maintainer of SQLiter responds in there pretty frequently
v
Thanks, I mentioned it there already before posting here, since I encountered these issued adding a native sample to Sqldelight.
k
I’m here 🙂
I don’t have much insight on building sqlite. We (generally) link against whatever is on the system, or sqlcipher, depending on the situation.
k
Without knowing much about the 
sqlite3.h
api surface, how does SQLiter deal with API changes/additions if dynamically linking against the platform lib?
k
sqlite changes are additive, generally speaking. It is one of the most delicate API’s on the planet, so you can be pretty sure that a published version isn’t going to have something significant changed in later versions (or at least that hasn’t happened yet). It’s more like they’ll add a new function instead. To add function calls with newer versions of sqlite that we’d want to support, you’d either need to add some supplemental cinterop, or we’d need to update sqlite’s header in SQLiter. However, the primary use case has been as the underlying driver for sqldelight, which limits what people call. Having said that, you can add a hook to modify the underlying db connection on create and destroy. So far I’ve only know of one team to use that: https://github.com/touchlab/SQLiter/blob/main/sqliter-driver/src/nativeCommonMain/kotlin/co/touchlab/sqliter/DatabaseConfiguration.kt#L59
k
So if SQLiter starts using one of those “additive changes” and the dynamically linked sqlite binary on a system doesn’t have that, what happens then? I assume that scenario hasn’t happened yet?
k
We’d think very long and hard about adding anything that might not be available. I wouldn’t just add something because somebody wanted to call it in a specific scenario. If you want to add something to your own project, you can just add a little extra cinterop with that specific call in it, and as long as you’re linking against a sqlite binary with that symbol, you can call it.
By “think long and hard” I mean look up min versions on android and ios, etc.
k
Gotcha, that makes sense! What I’m getting at is under what scenario would SQLiter consider doing a separate static and dynamic release similar to the jvm xerial lib.
k
Not familiar with it. Do you mean publishing sqliter with a packaged version of the sqlite binary?
As in, you could use a version of sqliter with a specific version of sqlite
k
This is mainly just curiosity speaking, by the way
k
I haven’t really thought about it. I’d guess demand. It’s also one of those situations where sqlite itself also has a huge pile of compiler settings. Technically speaking, though, it’s doable. I haven’t really had anybody ask about that kind of thing as I recall, although I have had some academic discussions about it (like this one 🙂 ). This really came up when trying to build a common driver for Android. You can’t link against the Android system driver, so if you want to do something other than the 
SQLiteDatabase
on Android, you have no choice but to ship your own version of the sqlite binary. Then, of course, it would kind of make sense to do that on iOS, but beyond discussing it, nobody’s really wanted it enough to get serious about it.
It’s also one of those situations where sqlite itself also has a huge pile of compiler settings
I’d have to look at xerial and see what they did, but if you’re building your own sqlite, I imagine it’s tempting to also tweak some of those. Maybe like a sqlite library generator Gradle plugin, which would have like 3 users, but would let you specify the sqlite version, and all the settings you want, and output a KMP sqlite library.
k
That would be pretty neat but sounds like a massive undertaking
k
Yeah, for sure, and by “which would have like 3 users” I mean literally you’d probably have about 3 teams ever bothering to use it. Would be cool, though.
v
Thanks for this discussion already. My questions mainly came up because I am hacking on the viability of using Kotlin Native for desktop applications, and in my trials I wanted to use Sqldelight for a real-world sample application. This caused various linker issues on my arch and ubuntu boxes.
k
I’ve done very little with linux builds. Linux support for sqliter was a contribution. I don’t know what you would expect to ship on system, if anything. As mentioned in this and the other thread, you can package binary into a klib and the Kotlin compiler will use that to satisfy the linker, but I’ve never tried it with sqlite. There was another sqlite KMP lib a few years ago that I think may have built it’s own sqlite, it definitely downloaded the header. I don’t have the link off hand (and am late for a meeting)…
v
no worries, both threads have already been helpful.
I'm going to have a look at packaging into the klib, so far I got it working by linking compiling my own sqlite3 and provide it to the final binary through 
linkerOpts
98 Views
Open in Slack
PreviousNext
Powered by