Does Kotlin Native have a module loading system th...

# kotlin-native

[napperley]

Does Kotlin Native have a module loading system that is similar to what can be found on some platforms ( https://stackoverflow.com/questions/384121/creating-a-module-system-dynamic-loading-in-c )? I would like to develop a Kotlin Native program that has a basic plugin system built in where certain functionality is loaded on demand, without requiring all C libraries to be available on the target platform. For example, one might develop a Kotlin Native program which generates performance reports that come in various types. One of these types is PDF which requires the Cairo library ( https://www.cairographics.org/ ) to be loaded, whereas the Console report just uses the built in platform libraries and doesn't require the Cairo library.

[ephemient]

you can create dynamically loadable libraries with K/N but as far as I know, each one will live in a separate Kotlin universe and can only interoperate with other code via C APIs

[napperley]

@Sebastian Sellmair [JB] - Sounds like the Kotlin team would need to add the module loading functionality to the KLib library format. I wonder if a member of the Kotlin team would be interesting in looking into the issue (feature request).

[ephemient]

at least currently, klib isn't something usable at runtime at all - the "linker" turning klib into binary/library is doing most of the actual compilation as well as linking

[napperley]

Information on the KLib format is difficult to come by.

[napperley]

Is the KLib limitation (link time only) set in stone, or could that change in the future?

[ephemient]

I don't know, but I would expect that any runtime linking done in the future would use the platform's shared library formats

[Sebastian Sellmair [JB]]

cc @svyatoslav.scherbina might be interested in this idea!

[svyatoslav.scherbina]

certain functionality is loaded on demand, without requiring all C libraries to be available on the target platform.

Plugin loading system is not actually required for this.

cc @svyatoslav.scherbina might be interested in this idea!

Which one?

[napperley]

The gist of the idea is to only load certain libraries on demand depending on the functionality that is used in a Kotlin Native program (based on user interaction). Two obstacles to this are the following:
1. All linked libraries are verified at runtime, if a single one is missing then the program crashes
2. KLib library format (needed for wrapping the C libs) only does things at link time, and has no flexibility to do things at runtime

[svyatoslav.scherbina]

We don’t have plans for this.
As for your particular case, it would be enough to load native libraries (like Cairo) on demand. Have you tried investigating this approach? E.g. with lazy binding or weak linking and dlopen.

[napperley]

I haven't investigated the approach, although this would be something that would be worthwhile trying via a Git Branch for experimentation. Some things were discovered recently like being able to use some platform/C types (eg CPointer) in the common module (was this introduced recently?), which is mind blowing and it isn't known how this would affect library loading (especially with third party C libraries). All of this of course is heading into uncharted territory 🛣️ .

[svyatoslav.scherbina]

Some things were discovered recently like being able to use some platform/C types (eg CPointer) in the common module (was this introduced recently?)

If it is the source set common between Native targets, then I guess this is the result of the long-term Kotlin initiative “Hierarchical project structure”.

which is mind blowing and it isn’t known how this would affect library loading (especially with third party C libraries).

I don’t see how this would affect.