I'm having trouble running SKIE acceptance tests w...

# kotlin-native

[Tadeas Kriz]

I'm having trouble running SKIE acceptance tests with Kotlin 2.1.0-RC. It crashes when NativeGenerationState calls LLVMContextCreate() and it crashes in native because it tries to call llvm::LLVMContext::setDiagnosticHandlerCallBack without passing in parameters. That leads me to believe there has to be something wrong with the libllvmstubs.dylib that it loads, but for some reason it works in other invocations outside of our acceptance tests.

What's weirder is that according to the crash any my debugging, LLVMContextCreate() calls llvm.llvm.kniBridge8() in Java code (generated stubs) which is a private static final native long kniBridge8(). But when I opened the libllvmstubs.dylib (located at ~/.konan/kotlin-native-prebuilt-macos-aarch64-2.1.0-RC/konan/nativelib/libllvmstubs.dylib) in Hopper Disassembler, _Java_llvm_llvm_kniBridge8 is really calling _LLVMContextSetDiagnosticHandler and it's the kniBridge7 that's calling _LLVMContextCreate.

I'm stumped because it should either crash in both invocations I'm trying, or it should work in both. But since it crashes when our acceptance tests invoke Kotlin/Native compiler but doesn't crash when building using Gradle, I expect there to be some kind of configuration issue going on.

Any ideas? Also, anyone has an idea what's up with the native symbols mismatch I mentioned?

[Tadeas Kriz]

I think I was able to figure out what's happening. The compilation that works is using a kotlin-native-compiler-embeddable.jar located at ~/.konan/kotlin-native-prebuilt-macos-aarch64-2.1.0-RC/konan/lib/kotlin-native-compiler-embeddable.jar. The llvm/llvm.class here calls the correct kniBridge7() from the LLVMContextCreate().

[Tadeas Kriz]

However our tests use the kotlin-native-compiler-embeddable.jar from Maven Central where the 2.1.0-RC jar's llvm/llvm.class calls the incorrect kniBridge8()

[Tadeas Kriz]

Would it be possible to get an RC2 released with a fix?

[svyatoslav.scherbina]

Hi.

Would it be possible to get an RC2 released with a fix?

It is too late for that -- no new commits are accepted to 2.1.0 at this point.

Also, I don't think it is a bug. We use different LLVM variants on different platforms. So kotlin-native-compiler-embeddable.jar is also different on different platforms. I would guess that the version in Maven Central is for Linux.
Regardless, that published version was never intended to be actually executed. It is more like an artifact to compile compiler plugins against.

In other words, libllvmstubs.dylib is only compatible with kotlin-native-compiler-embeddable.jar from the same compiler distribution. There is no binary compatibility between different versions of these artifacts.

Would it be possible to adjust your acceptance tests to load kotlin-native-compiler-embeddable.jar from the same compiler distribution as libllvmstubs.dylib and the rest of compiler parts? I would guess that either Gradle dependency substitution or `compileOnly`/`runtimeOnly` dependency configurations should help.

[Tatiana Bogdanova [JetBrains]]

Hi @Tadeas Kriz! Could you please tell me if the solution suggested above helped?

[Tadeas Kriz]

Hi, yes thanks, we've temporarily switched to the local distributable in ~/.konan. We'll try to implement `compileOnly`/`runtimeOnly` down the line.

I'm not sure if this behavior is documented (couldn't find it myself), but it'd probably make sense to document this behavior difference between the different artifacts in case other people hit the same limitation.