google-java-format_linux-x86-64: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./google-java-format_linux-x86-64)

[vorburger]

I'm using our cool new native build in a GitHub Codespace for the first time, and it unfortunately fails, like this:

./google-java-format_linux-x86-64: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./google-java-format_linux-x86-64)

From what I understand, the simplest solution for this which may be best in this context could be to statically link libc?

I'm guessing GraalVM Native can be asked to build it like so - but I don't immediately know how - what to add here...

... @dlicois / @natros / @fmeum do you happen to know how to do this? Fancy contributing a PR to fix this? 😄

@cushon FYI

[cushon]

It's theoretically possible to fully statically link native images, including libc, using musl: https://www.graalvm.org/22.0/reference-manual/native-image/StaticImages/

Another option is to do the build on a system with an older libc version (as suggested in oracle/graal#6183 (comment)), by downgrading the version of the image the release process is using, i.e. not using ubuntu-latest.

Yet another option would be for github codespaces to support the same version of ubuntu as github actions 🤔

[vorburger]

Yet another option would be for github codespaces to support the same version of ubuntu as github actions 🤔

But then this issue could still appear in other situations... I would suggest we look at this more like "it should just work" than "it should work in Codespaces which are based on Ubuntu vX" - WDYT?

Another option is to do the build on a system with an older libc version (as suggested in oracle/graal#6183 (comment)), by downgrading the version of the image the release process is using, i.e. not using ubuntu-latest.

The idea being that then it would work on most older and newer distros - because even newer distros would always also have all older versions of e.g. libc? Is that typically the case? (Honest question!)

It's theoretically possible to fully statically link native images, including libc, using musl: https://www.graalvm.org/22.0/reference-manual/native-image/StaticImages/

Isn't this the simplest? Any good reason why we would not want to do this? File Size? Do we care? (I don't.)

[cushon]

My understanding is that glibc is generally backwards compatible, so building against older versions and running against newer versions will work. So using a slightly older ubuntu image would be an easy way to make the image more compatible.

musl seems like an interesting option, and I'm not worried about optimizing for binary size either. It looks slightly more involved to set up, the graal instructions suggest downloading it and building it yourself. But if someone was interested in setting that up I'd be happy to review a PR for it :)

[vorburger]

So using a slightly older Ubuntu image would be an easy way to make the image more compatible.

==> #1075

FTR: I'm not sure if this will actually do the trick. But it can't really hurt either, so let's?

Fully static would probably still be better - if someone knows the configuration, do contrib. a PR!

[cushon]

I have made a release that includes the change to use an older ubuntu image: https://github.com/google/google-java-format/releases/tag/v1.21.0

@vorburger can you check if that fixes the issue you were seeing?

[vorburger]

@cushon yep, #1075 clearly did the trick; I've verified it (and bumped in enola-dev/enola#579). Resolved! Tx.