I have completely forgotten how to setup a Kotlin ...

# kotlin-native

[napperley]

I have completely forgotten how to setup a Kotlin Native project (for a Kotlin Native program) to use a dreaded C header only library 😱. The library being used in this case is LVGL ( https://lvgl.io/ ) via its Linux Frame Buffer ( https://kevinboone.me/linuxfbc.html?i=1 ) backend. At one point I had a Kotlin Native project that successfully used a C header only library (the third party library provided some GTK Chart widgets) but can't find it 😦.

@Artyom Degtyarev [JB] - Can someone please advise on how to use a C header only library in a Kotlin Native project that will generate a Linux program (an ELF binary).

[napperley]

Have found the magic incantation I was looking for. In the def file a linker option ( https://www.commandlinux.com/man-page/man1/gold.1.html ) needs to be passed through in order to get the linker to shutup on undefined symbols, eg:

linkerOpts = --warn-unresolved-symbols

After applying the incantation the linking process now works 😂. What could possibly go wrong? 😆

[Artyom Degtyarev [JB]]

Possibly related: https://stackoverflow.com/questions/58244150

[napperley]

The Kotlin program initially started on the Raspberry Pi with printing a message (Starting LVGL Test...), but abruptly exited with the following symbol lookup error:

undefined symbol: lv_init

Here is the project: https://gitlab.com/napperley/lvgl-hello

Something is missing for including the definitions from the header files into the binary itself. I did look at the Stackoverflow link but found there was a lack of details for using a C header only library in a Kotlin Native project.

[napperley]

@Artyom Degtyarev [JB] - The definition for lv_init is in the lv_obj.c file, how is the definition included from that file (incl its corresponding header file) into the binary file?

[Artyom Degtyarev [JB]]

So, that’s not a header-only library, correct?

[napperley]

Eventually managed to get the library working by generating static library files for both LVGL and its required LV Drivers library (provides the Linux Frame Buffer backend support - https://github.com/lvgl/lv_drivers ), however the build process is convoluted and until recently LV Drivers didn't use a build system (eg CMake).

[napperley]

Hopefully the LVGL team start to realise that Embedded Linux developers expect C libraries to be distributed in a form where both the header and static/dynamic library files are available or can be easily generated on the fly via a standard build system (Make or CMake).

[napperley]

Unfortunately I had to hard code the static library paths since the Kotlin Multiplatform Gradle plugin doesn't have the option to change the paths dynamically.

[napperley]

Since LLGL originated from the uC (Micro Controller) side there are some strange things done with reusable C code that would look very weird to Embedded Linux developers.