`GLIBC_2.32' and `GLIBC_2.34' not found error in AlmaLinux OS 8 and CentOS Stream 8.
hideishi-m opened this issue · comments
From 20230103.0.0 google-closure-compiler-linux fails with the following error on AlmaLInux OS 8 as well as CentOS Stream 8 (aka RHEL8 platforms).
/root/node_modules/google-closure-compiler-linux/compiler: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by /root/node_modules/google-closure-compiler-linux/compiler)
/root/node_modules/google-closure-compiler-linux/compiler: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /root/node_modules/google-closure-compiler-linux/compiler)
It does not happen with 20221102.0.1. Note that RHEL8 uses glibc-2.28.
Following is the Dockerfile to reproduce.
FROM almalinux:8
# FROM quay.io/centos/centos:stream8
WORKDIR /root
RUN dnf -y module enable nodejs:18
RUN dnf -y install nodejs
RUN npm install google-closure-compiler
CMD [ "/root/node_modules/google-closure-compiler-linux/compiler", "--version" ]
Following is the output with 20221102.0.1 without any errors.
Closure Compiler (http://github.com/google/closure-compiler)
Version: v20221102
Possibly related to #272 ?
Yes this changed with #272. In order to support multiple glibc versions, we are now dynamically linking against it. That means that the distribution requires having glibc installed.
There's no good way to support multiple glibc versions and static link to it. We had to choose one or the other.
Hello @ChadKillingsworth ,
I'm not against distribution of dynamically linked binary.
Because RHEL8 (and its compatible platforms) uses lower version of glibc, I'm hoping that if it is possible to build the dynamically linked binary on build environment with lower version of glibc. This will remedy to run google-closure-compiler-linux on RHEL8 environment.
Here's the GRAAL documentation on dynamically linked GLIBC: https://www.graalvm.org/22.2/reference-manual/native-image/guides/build-static-executables/#frequently-asked-questions
There's very little control.
Sure, you have - at least - some sort of control.
The root cause is that ubuntu-latest image is shipped with glibc-2.35 which mandates 2.32 and 2.34 ABI.
On the other hand, ubuntu-20.04 image is shipped with glibc-2.31 which is compatible with glibc-2.28.
If you could use ubuntu-20.04 image instead of ubunto-latest image for building the binary, this will link against glibc which is not bound to 2.32 nor 2.34.
Unless GRAAL mandates glibc-2.32+, using ubuntu-20.04 image could be an option.
I'm open to switching the build image. My only concern is at some point this will have to change. I'm wanting to target the largest possible number of users without creating a large maintenance burden.
By the way, because the root cause of #272 was the same as #280 that building image has been swithced from ubuntu-20.04 (former latest) to ubuntu-22.04 (current latest), it is also possible to go back to the static build as it was in 20221102.0.1.
Using static build may be better from the number of users perspective as we see in #277 where it uses alpine based image which may not bundle the required version of glibc.
Linux binary built in this pipeline https://github.com/google/closure-compiler-npm/actions/runs/3952305234 works perfectly!
Thank you for the fix, and await patiently to be released as npm in the next round.
We publish a nightly version, so you don't technically have to wait for a major release:
https://www.npmjs.com/package/google-closure-compiler/v/20230122.0.0-nightly
I may go back and revisit static linking with this info. It's definitely preferred.