Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install error: 'GLIBC_2.33' not found #1348

Closed
chgeo opened this issue Mar 14, 2025 · 8 comments · Fixed by #1349
Closed

Install error: 'GLIBC_2.33' not found #1348

chgeo opened this issue Mar 14, 2025 · 8 comments · Fixed by #1349
Labels

Comments

@chgeo
Copy link

chgeo commented Mar 14, 2025

With latest 11.9.0, I get this error:
10:04:52 INFO - npm error prebuild-install warn install /lib64/libc.so.6: version 'GLIBC_2.33' not found (required by .../node_modules/better-sqlite3/build/Release/better_sqlite3.node)

This happens on an older SLES image that worked just fine with the previous version of better-sqlite3.

I guess the change of the GLIBC baseline version was done by mistake, maybe done in #1341.

@chgeo
Copy link
Author

chgeo commented Mar 14, 2025

Similar issues from the past: #990, #403

@m4heshd
Copy link
Contributor

m4heshd commented Mar 14, 2025

This is one of the challenges we predicted in #1341. Unfortunately, we hardly have any alternatives other than going with a custom runner.

@chgeo
Copy link
Author

chgeo commented Mar 14, 2025

Have you checked on the options mentioned in #990 for decoupling the runner image from GLIBC (like using an older node base image)?

For the release process, I would expect a conscious decision on such a bump of the GLIBC baseline version. The 11.9 release notes do not mention this as a breaking change.

@m4heshd
Copy link
Contributor

m4heshd commented Mar 14, 2025

We already use the node:18-bullseye image for the arm builds. Can't remember exactly why we didn't go that route. Tests were done a long time ago.
As I've mentioned in #990 (comment) I tested this extensively and there were practical issues but just can't remember what those were exactly.

Anyways, @mceachen should chime in for this. He might remember or give you a good reason for why we try to keep build automation stuff as current as possible. For me, it's the constant need for maintenance and unintended outcomes. Might not apply to this very case, but that's something I'm accustomed to.

Although, in this case, I think we're okay with the node:18-bullseye container for now since the later node versions are good with glibc >= 2.28. What do you think @mceachen?

@chgeo
Copy link
Author

chgeo commented Mar 17, 2025

Any update here @mceachen ?

@mceachen
Copy link
Member

Indeed--I didn't think through the impact of the build runner upgrade. Derp.

I'm fine with running the builds in bullseye, and I think it's better to have the x64 and arm builds run in as similar a way as possible, if nothing more than to avoid possible inadvertent discrepancies between distros and build tooling.

@chgeo or @m4heshd if you can, please submit a PR to update the build.yml, I'll review it as soon as I can. (I can't self-approve PRs on this repo)

@mceachen mceachen added the bug label Mar 17, 2025
m4heshd added a commit to m4heshd/better-sqlite3 that referenced this issue Mar 17, 2025

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
This fixes WiseLibs#1348 by building the artifacts on a base Linux image with glibc 2.31.
@m4heshd
Copy link
Contributor

m4heshd commented Mar 17, 2025

@mceachen This should get it done.

mceachen pushed a commit that referenced this issue Mar 17, 2025
This fixes #1348 by building the artifacts on a base Linux image with glibc 2.31.
@chgeo
Copy link
Author

chgeo commented Mar 18, 2025

Thanks. I can confirm that 11.9.1 works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging a pull request may close this issue.

3 participants