I am in the process of preparing a multiplatform p...

# kotlin-native

[katokay]

I am in the process of preparing a multiplatform project to be published to maven for a Kotlin-centric API around LMDB key/value store located here.
https://github.com/crowded-libs/kotlin-lmdb

I am wondering if there is any creative ways to package the native libs directly with the klib? I've seen this issue that it's not currently supported here https://youtrack.jetbrains.com/issue/KT-24649

You can see my def file definition here that references the precompiled binaries matching the target name for supported targets. This is similar to how I needed to accomplish the same thing in .NET with nuget, however I don't see any options without the end-user being passed on this burden and ensuring the lib is in the path correctly before using. https://github.com/crowded-libs/kotlin-lmdb/blob/main/src/nativeInterop/cinterop/liblmdb.def

Any help would be greatly appreciated. Thanks

[Adam S]

hey 👋 , cool to see a KN key/value store

Did you want to embed a static library? https://kotlinlang.org/docs/native-definition-file.html#include-a-static-library

[katokay]

That could be a potential way to solve part of the problem. However, the lib is multiplatform and that leaves the lib / static .so, .dylib, .dll, .wasm problem unsolved for the jvm or wasm side of the same dependency unless I'm missing something.

[Matt Nelson]

You cannot distribute .so, .dylib, .dll files via a .klib publication unless you do something like base64 encode the precompiled native libs into a .kt file, compile that, and then have some sort of framework to extract that to a temp location at runtime and use `dlopen`/`dlsym`. from kotlin/Native (e.g. kmp-tor-common:NativeResource)

Additionally, you would need to codesign macos and mingw libs if you're loading things dynamically, otherwise library consumers would need to codesign them.

The simplest way is to have the kotlin compiler build the native code and embed it in the .klib bitcode. Checkout cklib for that.

[katokay]

Yes, but again that only solves the problem for the native lib correct? For the multiplatform story, seems to me that there's a larger opportunity for the ecosystem to ship native dependencies as part of the overall design. It's so common, that it seems like a big hacky burden to push this onto consumers, or library writers to base64 encode binaries into their packages.

That said, I appreciate the response and welcome the dialog.

[Matt Nelson]

IMHO, Kotlin should not provide the functionality of shipping dynamic libs in a .klib . There are so many falling knives (e.g. glibc versions). I only do that with kmp-tor because the tor C library is, well, very complicated.

If you're writing C code instead of Kotlin/Native, either do so in the .def file like:

package = my.package.internal
---
#include <errno.h>

static int
something()
{
  return 2;
}

or use cklib to compile the thing using the kotlin compiler.

[katokay]

cklib sounds more ideal for the native package, but reading stuff like "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." doesn't give me warm fuzzies down the road.