Has anyone managed to statically link their c file into kn executable? Looking for examples as my ex...

# kotlin-native

[Big Chungus]

Has anyone managed to statically link their c file into kn executable? Looking for examples as my experiments have all been failing so far

[Oleg Yukhnevich]

I will not say, that it will work in all cases, but you could try something what is done here:
task: https://github.com/whyoleg/ffi-kotlin/blob/new-runtime/build-logic/src/main/kotlin/bitcode/BuildBitcode.kt#L36
usage: https://github.com/whyoleg/ffi-kotlin/blob/new-runtime/libraries/libcrypto3/api/build.gradle.kts#L74
Note: highly experimental 🙂
BTW, this is how cinterop includes additional C declarations

[Big Chungus]

Thanks, that looks promising!

[vbsteven]

Since I know what this is in relation to for the glib-compile-resources: It might also be possible to generate a single .def file from the generated `.c`/`.h` files and use that as an additional resources cinterop?

[Big Chungus]

I tried that already. Flakey as hell 😄

[vbsteven]

ugh

[vbsteven]

if it's too much trouble or requires some unstable/experimental stuff, we might be fine with initially just compiling the resources to that binary format and loading it manually. That's the recommended way for GNOME/GTK anyway. And having it compiled fully into the finaly binary is a nice to have

[Big Chungus]

I've got it working, however every subsequent execution now fails with llvm complaining about function name clashes. It looks as if linker task is appending the file again each time on top of previous attempts. Any tips on what might be wrong?

[Oleg Yukhnevich]

Not sure about that specific case, but I’ve seen some errors, when bc file changes, but name left the same. Looks like it caches paths/files
As said, dangerous :)
However, if you just need to cinterop over those declarations, I will propose to not do ‘emit-llvm’ but compile to .o file, link it and include as static library

[Big Chungus]

Doesn't cinterop require .a files for static linking?

[Oleg Yukhnevich]

Yeap
And you can build them from .o files :)

So steps will be:
1. Compile your .c to .o using K/N clang
2. Build .a static lib from .o file, via llvm ar (OS specific, please google for more detailed examples)
3. Create .def which will link this static library and point it to your .h (CInteropProcess task should depend on static library building)
Should work I believe:)
Haven’t tried though

[Big Chungus]

Are there any flags to run_konan that would allow me to build .a via konan llvm to avoid yet another os dependency?

[Oleg Yukhnevich]

I believe K/N can do this (as it’s possible to build static lib there)
Though, need to dig a little to how it does this :)
As said, Haven’t tried that (yet)
Also I believe, llvm-ar executable should be somewhere inside .konan dir
(Not near PC now, so not sure, that I could help with location of code or executable)

[Big Chungus]

That's plenty helpful already. I'll see what goodies konan dir contains

[msink]

Simply including .c file at the end of .def does not work?

---
#include "your.c"

[Big Chungus]

Haven't tried that yet - clever!

[Big Chungus]

Shouldn't it be your.h though?

[Big Chungus]

It works with a little caveat - you need to add c file to cinterop dependencies otherwise it will be skipped as up-to-date

compilations["main"].cinterops.create("test") {
            dependencyFiles = project.files("path/to/cfile.c")
        }

[msink]

Well, and what if instead of including at the end - add that .c file into headers list in .def?
Will it work and will it be added to dependencies automatically?

[Big Chungus]

It works as well, but still requires explicit dependencyFiles

[Big Chungus]

That's what I'd expect. Probably related to the fact that the file is .c and not .h