02/04/2023, 10:39 PM
Would the K/N team accept contributions to fix running against a dynamically-linked LLVM? I'm attempting to package kotlin-native for nixpkgs, and they have a particular LLVM build that's difficult to coerce into creating a static library. The main change is a complete rework of libclangstubs' signal chaining mechanism on Linux, basically parsing the ELF dynamic section to locate the correct symbol to redirect in libLLVM. Right now it crashes because we iterate through all addresses in the GOT for libLLVM with no bounds check, when the actual symbol we need to patch lives in libclang on a dynamically-linked .so.


02/08/2023, 6:15 PM
Hi! Thanks for asking before doing a contribution :) Theoretically, we might accept, but I have a couple of questions first (I’m not familiar with Nix): 1. What is wrong with using the default Kotlin/Native LLVM? 2. What LLVM version nixpkgs has? 3. Why is it “difficult to coerce into creating a static library”? 4. At some point we will fork LLVM and solve this problem by patching its sources. How is it going to work with packaging Kotlin/Native in nixpkgs? 5. Who is going to test and maintain your fix, so it is not broken accidentally in some release? :)