8000 Solve GLIBC incompatibilty issues · Issue #2705 · wasp-lang/wasp · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Solve GLIBC incompatibilty issues #2705

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.

Sign up for GitHub

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

Jump to bottom
Open
sodic opened this issue Apr 28, 2025 · 4 comments
Open

Solve GLIBC incompatibilty issues #2705

sodic opened this issue Apr 28, 2025 · 4 comments
Labels
ci Continuous integration discussion shouldfix We should do/fix this at some point

Comments

@sodic
Copy link
Contributor
sodic commented Apr 28, 2025 •
edited
Loading

Why is GLIBC problematic?

Quick background for anyone unfamiliar:

  • GLIBC is the "GNU C Library", a core part of the Linux operating system. It's a bunch of wrappers around Linux kernel system calls (so it's essential for all programs).
  • Wasp's executable depends on GLIBC.
  • GLIBC is a dynamically linked library, meaning that it's not packaged into the executable during build. Instead, the executable expects to find it on the host system and "import" it dynamically.
  • Problems occur when you run a program on a system with a GLIBC version that's older than the one used when compiling (because then your program relies on features that don't exist on the host system).

So, what sometimes happens with Wasp:

  1. We compile wasp on a new Linux system with a recent GLIBC version (e.g., Ubuntu 22.04 with GLIBC 2.34).
  2. Users try to run wasp on an older Linux system with an older GLIBC version (e.g., Ubuntu 20.04 with GLIBC 2.31).
  3. Wasp fails because it can't find the newer GLIBC functions it relies on.

We usually fix the problem by telling our CI to use the lowest possible version for building Linux executables. This maximizes compatibility (explained here).

The current problem

Wasp will probably always break for some portion of users:

  • GitHub only allows us to build on Ubuntu versions still within their LTS period (the oldest being 22.04 at the time of writing).
  • Users are possibly still using older versions despite the LTS expiry (20.04 at the time of writing).

So there's always a gap between what Github allows us to build on and what some users are still running. This gap is largest immediately after each LTS expiry. Here's what happens when users try to run Wasp 0.16.3 on Ubuntu 20:

filip@ubuntu-20$ wasp version
/home/filip/.local/share/wasp-lang/0.16.3/wasp-bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /home/filip/.local/share/wasp-lang/0.16.3/wasp-bin)
/home/filip/.local/share/wasp-lang/0.16.3/wasp-bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /home/filip/.local/share/wasp-lang/0.16.3/wasp-bin)
/home/filip/.local/share/wasp-lang/0.16.3/wasp-bin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /home/filip/.local/share/wasp-lang/0.16.3/wasp-bin)

The main question is:

Does the problem affect a significant portion of our users and is it something we want to fix?

@Martinsos What do you think?

If so, I see two possible fixes:

  • Figuring out how to build Wasp with an even older, LTS-expired version.
  • Exploring how to link GLIBC statically (see here).

Motivation and references

This issue pops up every once in a while:
@sodic sodic added ci Continuous integration discussion shouldfix We should do/fix this at some point labels Apr 28, 2025
@sodic sodic changed the title Explore statically linking GLIBC or find a way to build on older systems Solve GLIBC incompatibilty issues Apr 28, 2025
@sodic sodic mentioned this issue Apr 28, 2025
Closed
@Martinsos
Copy link
Member

@sodic that is a good analysis! I am not sure at the moment what is the right move, it feels like we should investigate more. Maybe look into what others are doing.

There was this comment on that older issue:

If I were you, I would just do what the rest of the world does and build on a distribution like Alpine that uses musl. This will greatly simplify things.

That potentially sounds like an interesting direction, if it makes sense for our use case.

@Martinsos
Copy link
Member

musl sounds like the best direction possibly, but let's see if it really affect people.

@sodic
Copy link
Contributor Author
sodic commented May 2, 2025

Looks like it does: https://discord.com/channels/686873244791210014/686873245428875297/1367162171812745237

@sodic
Copy link
Contributor Author
sodic commented May 2, 2025 •
edited
Loading

I've manually built the latest Wasp version with Ubuntu 20, so Wasp 0.16.3 no longer has this problem.

If you have Wasp 0.16.3 and are still experiencing the issue, you must delete the old binary and pull the new one:

Image

That should fix it :)

@cprecioso cprecioso mentioned this issue May 5, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
ci Continuous integration discussion shouldfix We should do/fix this at some point
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Martinsos @sodic
0