I can compile it as a *.so, but if I loadLibrary it when I call the C code I get an UnsatisfiedLink error.

If I add JNI to the C library, and then compile it as a .so, and then loadLibrary it, then it does load and work (including the substrate C interop calls)

Is there any way of loading vanilla compiled C into the graal java runtime?

it will be slow and annoying to develop when every change requires a full native-image

(examining the symbols in the JNI .so there is a JvRegisterClasses call that is not present in the plain .so file. I think this has the magic that makes loadLibrary link it correctly)

it's been loooooong time since I touched C etc - does graal / jni support similar mechanism to LD_LIBRARY_PATH? That's how dynamic linking works in other languages/runtimes

it does. thats all set up. the loadLibrary of the vanilla code loads... it just then doesnt work when called

I think you need to do JNI in the JVM still so you have to maintain two versions of the FFI code

Cc @U0A74MRCJ

yeah thats what I thought too. Just hoping someone with more experience shows me a magical graal blessed way that I dont know about 🙂

have to go sleep now. But will check back in the morning if anyone has any better solutions.

I've started writing all my ffi code using dtype-next's ffi since you can define the interface once and use it in a number of contexts. I'm not sure it covers the exact contexts you've listed, but I think it does. If it doesn't, the ffi interface is extensible. https://github.com/cnuernber/dtype-next/tree/master/examples/clj-ffi

Good tip!

@U7RJTCH6J that looks really great! I will give that a go. Thanks for the pointer.