Right, but this approach could be a blocker in situations like: • Some CVE or something forces us to update the underlying OS and or glibc tooling • native-image starts requiring a newer glibc The approach does makes it safer in a defensive sense, but seems to me like a blocker if we get hit by things like above? The OS/glibc is our JVM here and if and when that changes, its a breaking change we need to accept? I guess at some point clojure too might need jdk 11 or something and that's the same issue like this 😅 we should put this check in now, but id also like to explore ideas which solve this for a longer run?

The check at least makes us aware when we upgrade libc. We can then always make the choice to violate that rule. I don’t think native image will soon require specific versions of libc

yeah makes sense to add the check in now and also fail if its > 2.31 and see what happens. as for the glibc updates, i was referring to the release notes which said they need 2.17 or higher glibc

also i guess at this point we could build a reusable lib on bb tasks or something for clojure native-image CI so that similar projects can use it and all the headache is on one place 😛 i think we have uncovered a lot of pain points to abstract over?

we have bootstrapped bb too for this 😄

The idea being the CI its running on just sets up an agreed upon env and calls the tasks in order