Hypothetically speaking If the Kotlin Native team ...
# kotlin-native
n
Hypothetically speaking If the Kotlin Native team were doing third party Kotlin Native wrappers for the GObject libraries (GTK, Pango, Cairo etc) how would they do it (including handling complex C library dependencies)? GTK is well known for having complex C library dependencies, which are so complex that it isn't possible to statically link GTK itself.
d
Knowing them, they'll compile the header and leave linking to consumers.
n
Is there a example of this technique in action?
How would the consumer (a Kotlin Native library/program) do the linking when it isn't done at the Kotlin Native library level (on the producer side)?
With the KotlinX Coroutines library it handles the linking.
d
I've done this in
kgl-glfw
.
I compile the headers and provide a interface.
Then a consume can install the glfw locally, and simply specify it their link line and all the symbols will magically resolve.
Another interesting thing I've done is provide
kgl-glfw-static
, where it's an empty KLIB with a static library. Just by adding that dependency all the symbols are automatically resolved statically.
So my consumers can choose between static linking and dynamic linking.
n
Is the linking only applicable to a Kotlin Native program, or does it also apply to a Kotlin Native library (acting as a consumer)?
d
It only applies to a program. If a library consumes
kgl-glfw
they don't have to specify any linker stuff.
Although, unit tests count as a program, so it's debatable.
n
There are cases where a Kotlin Native library would need to depend on another Kotlin Native library (has dependencies on some C libraries) to access certain C libraries.
d
If it runs unit tests (the consumer library) it will have to specify in the link line for the test executables. Should be easy enough in a controlled environment
n
Would that mean only the linkerOpts property would need to be set in a def file on the consumer side?
d
It would be specified in gradle, but yeah pretty much.
n
Tried it the other day, and it works as expected simple smile . It should be established as best practice when developing a Kotlin Native library to NOT include any linking metadata.