Clojurians Log v2

It doesn't seem so

They wrote in the 21.3 release notes: • Changed the way the compiler is looked up when creating static, `musl`-based native images to use the `musl` toolchain from https://www.graalvm.org/release-notes/21_3/musl.cc. The `musl` toolchain greatly simplifies the creation of static native images. Using a toolchain also ensures minimum changes will be needed on users’ side to create a dynamically linked `musl` based image. See the https://www.graalvm.org/reference-manual/native-image/StaticImages/.

source: https://www.graalvm.org/release-notes/21_3/

👀

As far I understood, they changed from calling musl-gcc to x86_64-linux-musl-gcc

@borkdude I don't think the upgrade should cause too much issues, maybe the only thing we will need to change is to add a symbolic link pointing from musl-gcc to x86_64-musl-gcc

Another option would be to change to this http://musl.cc toolchain

BTW:

~/Projects/nixpkgs bump-graalvm
❯ nix path-info ./result -S -h
/nix/store/zprgwm11wl2798whkkifwsxsv45cchg4-babashka-0.6.1	110.9M

~/Projects/nixpkgs bump-graalvm
❯ nix path-info $(nix-whereis bb) -S -h
/nix/store/fay0p3hiiic4kd4fk0xyczl1ff8sjcp1-babashka-0.6.1	120.9M

It seems that GraalVM 21.3.0 will reduce the binary quite significantly

I saw a 10mb reduction in bb with 21.3.0 but when upgrading to jdk 17 it gained 10mb again ;)

btw, why is bb so big on nix... this surprises me. in #babashka you can see that the size is 80-90 mb for each os

This is the whole closure size, including the libraries

So in this size it also includes glibc

that's called a closure in nix?

ah I see, the entire environment

Yeah

neat

glibc should be 20MB

So this explains the difference

(BTW, before the babashka closure was 2GB because we also included the whole GraalVM)

I recently fixed this on a PR

haha wow