Clojurians Log v2

i have a question, it may be obvious, but why all the native image build guides for Clojure recommend --initialize-at-build-time ?

@huahaiy Have you tried without this flag?

yes, i did, and it failed. clojure.lang.PersistentList$EmptyList etc. will be initialized and it is not allowed.

so it is because initializing these at build time is unavoidable?

Afaik build time = better for perf, but sometimes you need to delay this until runtime because of side effects like starting threads

ok, thanks. the reason i asked is because some guys in graalvm channel seems to think that initialize at build time should be exception rather than the norm.

the problem i am trying to solve is to build native image on windows, it fails with “other” has different root

@huahaiy You can override this for some classes with --initialize-at-runtime=foo.bar.Clazz

https://gist.github.com/huahaiy/2b2fb178fd030cedc104ac4a18157e2e

Your issue also seems related to the reflection issue with clojure.lang.Reflector

WARNING: Method java.lang.reflect.Method.canAccess(Object) not found.

i don’t have a windows machine, so i have to use github action, they put the files on different disk, hence the error i guess

https://github.com/lread/clj-graal-docs#jdk11-and-clojurelangreflector

that one is ok, i have that in linxu and mac as well

they build just fine

I do have a Windows machine, I could test tomorrow

if you have some clear instructions

that would be great

i can check in the workflow yml file that i used for testing windows build on github actions, would that be sufficient?

@huahaiy Are you absolutely sure it's not related to the reflector issue? Fatal error:java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: 'other' has different root # Static libraries: at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

Try to add the suggested config from clj-graal-docs

right, that’s the error

yeah, might not be related, but one less thing to worry about

i think i know why, it’s because there are two disks involved c:\ and d:\

the compiler has trouble dealing with that

why does it have 2 disks?

if you have windows machine, you will probably not have the problem

github actions put user file under d:\ and their own libs under c:\

i guess that confused the compiler, hence the error

maybe try appveyor. I build all my graalvm stuff there for Windows

honestly Github actions is quite slow too compared to the rest (CircleCI, Appveyor)

cool, let me try that

do you have an example config that i can steal?

https://github.com/babashka/pod-babashka-buddy/blob/main/appveyor.yml

thanks!

yes, github action is very slow, it took like 13 minutes to build datalevin

thanks a lot, I will go try appveyor

@huahaiy if you need any example also, you can check clojure-lsp as well: https://github.com/clojure-lsp/clojure-lsp/blob/master/.github/workflows/release.yml#L47-L266

I use github actions for windows graalvm compilation 🙂

A couple of things GitHub Actions have that are kinda nice if you need/want them: macOS in the free tier and more RAM.

it takes 8mins to build each platform

i guess it is because i build datalevin twice, once for the command line tool, once for the native tests

I’m currently on GitHub Actions for rewrite-clj v1 where I do some GraalVM native-image testing.

thanks for the example. I will see if it helps. one thing that might be different is that i do need to build C code

rewrite-clj / clj-kondo / clojure-lsp aren't such heavy tools, but as soon as you require a little bit more, Github actions really shows that it's just built for "actions" on your source code, rather than building stuff with good performance. Probably good enough for JavaScript projects

i suspect that’s where the different root problem come from, when loading the built c lib

thanks a lot, i will try some options