Repository navigation
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) #1072
Description
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
Activity
cushon commentedon Feb 23, 2024
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 🤔
Document "jar-file" option on README
vorburger commentedon Feb 23, 2024
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?
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!)
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 commentedon Feb 24, 2024
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 :)
Build native on Ubuntu 20.04 instead of latest 22.04 (re. google#1072).
vorburger commentedon Feb 26, 2024
==> #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!
Build native on Ubuntu 20.04 instead of latest 22.04 (re. #1072).
fix (ide): Fix google-java-format in Codespace
fix (ide): Fix google-java-format in Codespace
cushon commentedon Mar 6, 2024
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?
fix (ide): Bump google-java-formatter from 1.20.0 to 1.21.0
vorburger commentedon Mar 7, 2024
@cushon yep, #1075 clearly did the trick; I've verified it (and bumped in enola-dev/enola#579). Resolved! Tx.
fix (ide): Bump google-java-formatter from 1.20.0 to 1.21.0
fix (ide): Bump google-java-formatter from 1.20.0 to 1.21.0
fix (ide): Bump google-java-formatter from 1.20.0 to 1.21.0