Hello, I am working on a project that is using a prebuilt static .so file and generated .h with cint...

# kotlin-native

[Kolby Kunz]

Hello, I am working on a project that is using a prebuilt static .so file and generated .h with cinterop in kotlin-native. Currently the project will build and compile just fine when none of the methods from the .so file are reference. Once I reference the functions from the .so and attempt to compile my code I am getting a linking error on both linux and macos. The error occurs in the linkDebugExecutableNative step and the error reads out

Undefined symbols for architecture x86_64 '_askar_version', referenced from _askar_askar_version_wrapper76 in result.o ld symbol(s) not found for archutecture x86_64

From what I understand the linker cannot find the definitions for the package for the target platform and is most likely looking in the standard include folders throughout the system but because it is a custom package they are not located there. Any advice on how to fix this would be greatly appreciated or if this is even something supported by cinterop.

[vbsteven]

Did you add the path where the .so file lives to the linkerOpts in your .def file?

[Kolby Kunz]

No, that would be something good to do. Can you point me to an example of what that should look like?

[vbsteven]

linkerOpts.linux = \
    -L/usr/local/lib \
    -lgobject-2.0 \
    -lglib-2.0

[vbsteven]

-L adds it to the search path (not 100% sure on the terminology), -l tells the linker to link against the library with the given name

[vbsteven]

in this case it means, look for libraries in /usr/local/lib and link against gobject-2.0 and glib-2.0

[Kolby Kunz]

Since it is static would it be fine to link to a location within the project?

[vbsteven]

There is also an additional flag you can pass to the linkeropts to put it in verbose mode, and then it outputs which locations it is looking in and what libraries it is looking for

[vbsteven]

Sure, that shouldn't be a problem

[Kolby Kunz]

Thank you I will look into to this

[Kolby Kunz]

Seems to be finding the directory correctly but the linker is now saying

library not found for -llibaries_askar

the .so is spelled incorrectly so it made sure to match the file name exactly. Not sure what to test next.

[vbsteven]

Can you show the full def file?

[Kolby Kunz]

package = askar
headers = ariesAskar.h
headerFilter = ariesAskar.h

staticLibraries =  libaries_askar.so


linkerOpts.macos_x64 = -Laskar/x86_64/ -llibaries_askar

libraryPaths = askar/x86_64

[vbsteven]

it's a bit weird that you have staticLibraries and then point to an .so file which is a shared library

[Kolby Kunz]

Good to know. Was not positive on the definition for this library. Looking into where I was provided the library from it comes from a Rust library and is being used into other projects as c-callable from the given .h file.

[Kolby Kunz]

After looking into the linker itself the

-l

flag looks fora file with lib appended to the front of it. Knowing that the linking option should now be

aries_askar

causes the compilation to succed