@borkdude - question re: the rust-clojure interop repo you built — I used it as a basis to compile a tool I'm building. It works on the machine I compile with, but when I move the binary to another computer it fails with a java.lang.UnsatisfiedLinkError — did you ever run into this?
My guess is that you're not doing a static binary
So the resulting binary assumes some libraries must exist on the machine for it to dynamically link against it
Try adding the static option
Ah, that might be it. Thanks @didibus . Looks like you can't compile static on mac? Guess I'll have to set it up on my linux box.
Hum... Were you doing Mac build and running it on Linux?
Cause that also for sure won't work.
I also think cross-compilation isn't there yet for Graal
Nah I was doing mac build and moving it to another mac.
@tees The idea is to copy the dynamic library from the resources to the filesystem and load it from there at startup: https://github.com/borkdude/clojure-rust-graalvm/blob/044ef3c921e7b2c9058e431a62574d85b1079011/clojure/src/clj_rust/core.clj#L10
Ah. Sounds like perhaps it is not entirely possible to have a totally self contained binary with two languages.
@tees The problem is that you cannot load native libraries from within your bundled resources. That's why you have to spit it out first. But this doesn't have to be visible to the end user
Ah, so it seems like the linked function you posted above happens at compile time? And I would just switch that to happen at runtime?
err, I see that it's transferring it from the resources to the home directory - so I guess the binary packages the lib, and then on runtime it should be copying it to my home dir.
yes, at runtime there is a check to see if the lib is there, and if it isn't, it's copied
I see there is no check if it's already there, but that could be implemented as well of course
Hm, I must have messed something up on my own version; I'll double check what's happening in my code... (edit: it was just because my resources were failing to get included for some reason.)