Are KN binaries statically linked by default? Or is it standard practice to provide linkerOptions in...

# kotlin-native

[Charlie Tapping]

Are KN binaries statically linked by default? Or is it standard practice to provide linkerOptions in the gradle DSL? I tried to run a binary in a scratch container but it was no bueno 😞

[Charlie Tapping]

To answer my own question, no its not at all. You can check for yourself by running:
objdump -p ./program.kexe | grep NEEDED
In my case I found that the following libs are dyn linked:

NEEDED       libresolv.so.2
  NEEDED       libm.so.6
  NEEDED       libpthread.so.0
  NEEDED       libutil.so.1
  NEEDED       libcrypt.so.1
  NEEDED       librt.so.1
  NEEDED       libdl.so.2
  NEEDED       libgcc_s.so.1
  NEEDED       libc.so.6
  NEEDED       ld-linux-x86-64.so.2

This is quite odd considering I’m running println(“Hello world”) that it would need anything else but libc

[Landry Norris]

The K/N runtime library needs those. The way it's designed right now, you get the full runtime, regardless of what parts you need.

[Charlie Tapping]

Interesting thank you! I guess having a true statically linked binary is out of the question for kotlin native given the dependency on glibc in there ?
@Landry Norris

[napperley]

If glibc is used then it always has to be dynamically linked due to the way the standard C lib (is the defacto one for Linux) is designed ( https://stackoverflow.com/questions/2856438/how-can-i-link-to-a-specific-glibc-version#comment29893178_2858996 ). Applies to any programming language that uses the library, especially C.