What are the implications of the fact that native ...

# kotlin-native

[Adolfo Ochagavía]

What are the implications of the fact that native support on Windows is MinGW-based? Imagine I have a Kotlin library, compiled as a DLL. Can I use it from e.g., Python, which is compiled using the MSVC toolchain? I have a prototype and it seems to work, but I'm asking to be sure things won't accidentally explode depending on which functions are called.

[Adolfo Ochagavía]

Similarly, I've tried to statically link the library from a Rust project (also MSVC-based), but there I'm seeing about 70 link errors related to missing symbols that seem related to the C++ runtime (e.g., __mingw_vsnprintf, pthread_mutex_init, etc).

[ephemient]

it's not even just a mingw thing - Windows didn't have a standard C runtime in the OS, and every C compiler had its own - and there are multiple versions of MSVCRT - with the result that mixing between them has always been a problem

[Adolfo Ochagavía]

I'm a bit confused that it works on Python but not on Rust... I guess maybe Python might crash at runtime if the missing functions are callled.

[Adolfo Ochagavía]

In any case, would it be correct to assume that I can't link to a kson-native library from a MSVC-based environment?

[ephemient]

it's likely that Rust exercises a different subset of the CRT than Python does

[ephemient]

I'm not actually sure if it even uses MSVCRT or UCRT or what, maybe Rust doesn't even use either, in which case if your librar is the only source of a CRT then mingw is fine

[Adolfo Ochagavía]

Assuming Rust doesn't use one, I guess I could link the C runtime from MinGW and it should work. Is that what you mean?

[Adolfo Ochagavía]

Though I wonder if this is a robust solution... My objective is to let people use my kotlin library from other languages, hassle-free. It would be a pity if adding a dependency on my library could result in unexpected link conflicts because we are shipping the MinGW C runtime, for instance.

[ephemient]

https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64-doc/howto-build/ucrt-vs-msvcrt.txt it seems that newer versions of mingw-w64 can be configured to use UCRT, which is as close to a standard CRT as Windows has ever had

[ephemient]

doesn't really help with programs linked with older MSVCRT though, and also Kotlin/Native is using an older version of mingw-w64 anyway

[ephemient]

basically Windows is cursed

[ephemient]

it's broken even for MSVC unless you're on the same version https://siomsystems.com/mixing-visual-studio-versions/

[Adolfo Ochagavía]

Thanks!

[Adolfo Ochagavía]

I'm a bit out of my depth here, but I take this to mean that Kotlin is not a suitable language for implementing a cross-platform, cross-language library (due to poor Windows support in kotlin-native). I don't find that too surprising, but I was hoping to avoid reimplementing the existing library in a lower-level language such as C or Rust.

[Adolfo Ochagavía]

Or would dynamic linking make a difference here?

[Adolfo Ochagavía]

(For reference, I tried to dynamically link the kotlin library from msvc-based-Rust, but calling basic kotlin functions such as createNullableInt crash the process with a STATUS_ACCESS_VIOLATION, even though the initial call to mylib_symbols succeeded.)

[Adolfo Ochagavía]

As a sanity check, I tried to dynamically link the kotlin-native library from a C codebase using MSVC and it worked. So I guess I must be doing something wrong in the Rust end. Update: I can confirm there was a bug in my Rust implementation. Now the DLL works 🙂