Fork me on GitHub
#graalvm
<
2021-09-16
>
ericdallo12:09:47

Sharing here as it's a good example of embedded Graal configuration with C files which I didn't see before in any other Clojure Graalvm compiled lroject

borkdude12:09:41

@ericdallo can you tell me more what is specifically new about this project? I don't know where to look.

ericdallo13:09:00

I think there are some details how @huahaiy did it https://github.com/juji-io/datalevin/issues/44#issuecomment-920596489, but AFAICS there is a new jar with the native stuff inside it that already has the C files built-in

ericdallo13:09:33

> Like all Clojure applications, class initialization needs to be done at image build time, otherwise, native image build will fail due to link errors. During the native image build time, our class initialization code extracts native libraries from the `datalevin-native` jar and put them in the GraalVM's default `CLibraryPath` for the platform (e.g. `${GRAALVM_HOME}/lib/svm/clibraries/linux-amd64/`). Make sure you have write permission for the directory. About this part: > Make sure you have write permission for the directory. @huahaiy Unfortunately this won't work for nix users like me :(

ericdallo13:09:48

Maybe we could have a custom java class that creates a temp dir, move the C files and add the custom flag to graalvm to use that dir as the c files?

borkdude13:09:34

> put them in the GraalVM's default `CLibraryPath` for the platform (e.g. `${GRAALVM_HOME}/lib/svm/clibraries/linux-amd64/`) It doesn't seem like a good idea to me to write build-specific native libraries into the system installation of graalvm

☝️ 2
Huahai14:09:05

the files are deleted on Java exit

ericdallo14:09:02

But if user has no write permission on that folder it won't work, right? Do you think we can try that temp folder idea?

Huahai14:09:11

The reason for doing this is to support windows, as windows temporary directory path is not certain

ericdallo14:09:57

we can use project directory where probably has a bigger chance to user has permission on that and then delete after the compilation, right?

Huahai14:09:42

since CLIbraryPath is not programmatically configurable, there’s no way to specify it in our code, only as an option, that is to say, it has to be hard coded in config, which doesn’t work

ericdallo14:09:16

There is no way to configure CLIbraryPath via java?

Huahai14:09:27

i have not figured it out

😔 2
Huahai14:09:01

it seems it’s in SubstrateOption, where everything is final

borkdude14:09:20

good question for the graalvm slack perhaps

☝️ 2
Huahai14:09:45

basically, it’s a trade-off, do we ask user to confgure or not

Huahai14:09:21

the alternative is to force user to set an environment variable, which would work, but it’s extra configuration required

borkdude14:09:29

Perhaps offer both options: if the defaults do not work, let the user override them

borkdude14:09:07

writing into a system installation might also be seen as suspicious by virus scanners etc. feels like a hack

Huahai14:09:36

graalvm is user installable though, they can install wherever they can, just like jvm

Huahai14:09:43

so it’s not part of the system

Huahai14:09:19

in fact, most compile script setup their own graalvm environment, is it not?

Huahai14:09:01

i originally had an environment variable, but i took it out

borkdude14:09:04

I haven't seen compile scripts that download their own version of graalvm

ericdallo14:09:16

the env var seems better I think

borkdude14:09:26

often people install graalvm via tools like sdkman, or whatever

borkdude14:09:35

I usually download it manually

Huahai14:09:53

it is error prone, for the path pointed to by the env var must exist

Huahai14:09:01

for the compiler checks for that

ericdallo14:09:02

yeah, for nix users for example, everything installed is imutable and doesn´t allow to write

borkdude14:09:08

so for me personally it's not a problem, but still, I don't like the idea of tools messing with my graalvm install. what if there is a bug and the tool removes stuff by accident for example. no.

Huahai14:09:39

so the alternative is to add back this environment variable, sure, I can do that

ericdallo14:09:55

thank you @huahaiy that would be a great alternative :)

Huahai14:09:02

but that would not be “configuration free” then

Huahai14:09:19

it’s good to have options, i agree

👍 2
ericdallo14:09:00

I'd still suggest ask on graalvm slack if there is an option to override that programatically

Huahai14:09:10

i will ask there

💜 2
Huahai16:09:29

An env var is added in 0.5.14. Thank you all.

🎉 4
borkdude16:09:22

They didn't reply in the slack I see. Ah well.

borkdude16:09:42

Probably native-image was the better channel to drop this question

Huahai16:09:28

well, they probably got too much other work to do, also they seems to prefer lock things down rather than opening it up i sense

borkdude16:09:51

Thanks for the effort!

Huahai16:09:41

they don’t like me asking in two channels, general have more people so i thought it is better ask there

borkdude16:09:22

There is also a Github Discussions board where you can ask btw, I've had some luck over there as well

Huahai16:09:20

good to know, going there

borkdude12:09:25

@huahaiy In other new, the --initialize-at-build-time will be deprecated in GraalVM 22. You should then remove it from your properties and use a library like https://github.com/clj-easy/graal-build-time to take care of this.

Huahai14:09:42

Will do, thanks

Huahai16:09:16

Done. It worked. Thank you for the library.