Change:
doInstallCheck = true; installCheckPhase = '' <del> $out/bin/bb --version | grep '${version}' $out/bin/bb '(+ 1 2)' | grep '3' $out/bin/bb '(vec (dedupe *input*))' <<< '[1 1 1 1 2]' | grep '[1 2]' </del> <ins> $out/bin/bb --version | fgrep '${version}' $out/bin/bb '(+ 1 2)' | fgrep '3' $out/bin/bb '(vec (dedupe *input*))' <<< '[1 1 1 1 2]' | fgrep '[1 2]' $out/bin/bb '(prn "bépo àê")' | fgrep 'bépo àê' </ins> ''; # As of v1.2.174, this will remove references to ${graalvmDrv}/conf/chronology,

Discussion:
After babashka can't display Unicode characters I have a babashka script that outputs the following JSON: The text is a Nerd Font Symbol code point. After the output is: Steps to reproduce the behavior: This has been fixed in the past by I did not test other packages that could be affected by the PR.
Pretty sure this is related to this bug in GraalVM upstream: I am curious if this is affecting projects using GraalVM 21.0.0 vanilla or if not, how is it working and why it is broken in .
It does seem that even setting up inside the C compiler environment is not sufficient to make it work. CC to see if they have more context on what the possibly issue is.
I also hit this today. I tested the same version(v1.3.186) from upstream binary release, which does not have this issue. Shall we always sync the same version of graavm as upstream build ci?
I don't think this is the issue and even if it was, it is not like babashka is the only GraalVM package we have.
I know that folks can't reproduce this issue with upstream, but I also can't reproduce it with GraalVM using Java, e.g.: A patch if anyone wants to test to be applied to : So, can anyone reproduce this issue with GraalVM Native Image itself? If not, the only thing I can think is that the issue here is the GCC (i.e.: non-static) version (upstream compiles with by default). Or something else.
So I got this warning: But this was after already started to build, so I assume this is the same issue as and need to be fixed upstream.
To explain in more details why I think this is an upstream issue: I don't get the same in the initial part of the build, only when the build starts that I get this warning. So what I assume is doing: Running the CC (C Compiler) inside a shell with clean environment We see the , because this shell couldn't set the proper locale thanks to missing environment variables (e.g.: ) Since this shell environment has no environment variables (at least, not the environment variables that we need), this ends up breaking macOS compilation and locale (Unicode) support in Linux Not sure why it works in GraalVM itself though yet. This is all really strange.

While I'm not familiar with graalvm, I do find a hack for this issue, maybe can weigh in to test whether this hack is valid: Some inspiration from a random reddit post and those issues: And I do find it's using , so I thought if I those two into build args, maybe it'd work. And indeed it seems to work.. After I built bb with above args,
BTW, I cannot reproduce with GraalVM Native Image on helloworld java as well. Helloworld produced by GraalVM Native Image has correct unicode output.
Thanks for investigating this issue. Opened so we can have this fixed.