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

Fails to start: Version GLIBC_2.33 not found #1528

Open
mason1920 opened this issue Jan 27, 2023 · 36 comments · May be fixed by #1541
Open

Fails to start: Version GLIBC_2.33 not found #1528

mason1920 opened this issue Jan 27, 2023 · 36 comments · May be fixed by #1541
Labels
Type: Bug-Fatal A bug making the App unusable

Comments

@mason1920
Copy link

OS: Debian 11.6
Launcher Version: v1.1.30-beta.1
Formats: Snap, AppImage, Debian

Log
Summary: Cannot open nsfw.node: libc.so.6: version GLIBC_2.33 not found (required by Chromium) at electron.js

Similar: #851 #890 #1044

@Eskaan
Copy link
Collaborator

Eskaan commented Jan 28, 2023

Unsure what to do with this. Could you investigate what dependencies you need to install to get it working?

@Eskaan Eskaan added the Status: Awaiting Feedback This will be closed whitout feedback. label Jan 28, 2023
@PassiveLemon
Copy link

OS: NixOS
Launcher Version: v1.1.30-beta.1
Format: AppImage

I get the same a GLIBC error as well. Log is here
My log looks a touch different but it looks to be the same error. I am not sure what I need to do to fix this since I already have the glibc libstdcxx5 and gcc packages in my system config.

@Eskaan
Copy link
Collaborator

Eskaan commented Jan 28, 2023

The problem is that it works perfectly fine on my arch install. I never encountered it and can't reproduce it even when trying. My glibc version is 2.36-7.
Someone that can reproduce it will have to fix it as I can't fix something that is not broken on my side.

@Eskaan
Copy link
Collaborator

Eskaan commented Jan 28, 2023

What glibc version do you two have?

@PassiveLemon
Copy link

I have 2.35 according to ldd --version

@PassiveLemon
Copy link

I really am at a loss here. I've tried loads of different packages but the only somewhat related issue had to do with glibcxx versions in Conda.

@Eskaan
Copy link
Collaborator

Eskaan commented Jan 30, 2023

I just spoke with another moderator on our Discord and he says this is a permissions issue. Could you try running with sudo to confirm that suspicion?

@Torgas
Copy link

Torgas commented Jan 30, 2023

Hi, i am experiencing the same issue on Debian stable 11.6, same glibc version reported by ldd-version

Issue seems to be related to glib version as on stable debian we now have 2.31 (source https://tracker.debian.org/pkg/glibc) and current GDLauncher requires 2.33 .

There might be tricks to install newer version into Debian stable but not a clean and maintainable one. Easiest way might be to upgrade Debian installation to testing (despite the name it is pretty stable).

Due to some personal reasons it is not option for me so i have tried to recompile GDLauncher from 1.1.30 tag on Debian stable and it seems to be working well.

Which leads me to idea problem might be related to build environment you guys are using to prepare official deb packages, maybe it is prepared on Ubuntu? As 22.04 LTS have Glibc 2.35 . But it is just guess.

If it helps i can provide deb package built on Debian stable.

@ClaudiusMinimus
Copy link

ClaudiusMinimus commented Jan 30, 2023

Same issue Linux Mint 20.3

A JavaScript error occurred in the main process
Uncaught Exception:
Error: Cannot open /tmp/.mount_GDLaunFRlOFJ/resources/app.asar/build/native/nsfw.node: Error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/.org.chromium.Chromium.DpvoZI)
    at Object.<anonymous> (/tmp/.mount_GDLaunFRlOFJ/resources/app.asar/build/electron.js:2:2736106)
    at ./public/native/nsfw.node (/tmp/.mount_GDLaunFRlOFJ/resources/app.asar/build/electron.js:2:2736144)
    at i (/tmp/.mount_GDLaunFRlOFJ/resources/app.asar/build/electron.js:2:124)
    at ./public/nsfw.js (/tmp/.mount_GDLaunFRlOFJ/resources/app.asar/build/electron.js:2:2736280)
    at i (/tmp/.mount_GDLaunFRlOFJ/resources/app.asar/build/electron.js:2:124)
    at ./public/electron.js (/tmp/.mount_GDLaunFRlOFJ/resources/app.asar/build/electron.js:2:2723428)
    at i (/tmp/.mount_GDLaunFRlOFJ/resources/app.asar/build/electron.js:2:124)
    at module.exports../node_modules/base64url/dist/base64url.js (/tmp/.mount_GDLaunFRlOFJ/resources/app.asar/build/electron.js:2:923)
    at Object.<anonymous> (/tmp/.mount_GDLaunFRlOFJ/resources/app.asar/build/electron.js:2:953)
    at Module._compile (node:internal/modules/cjs/loader:1118:14)
Killed

I searched and found upgrading to GLIBC_2.33 can open a can of worms I don't feel like dealing with.

Also, after attempting to run 1.1.30 makes it challenging to revert to 1.1.29. I have to kill all gdl processes and then re-download the 1.1.29 appimage file. And not surprising, I have also tried the .deb file and it fails too.

@PassiveLemon
Copy link

I am not super familiar with the inner workings of this stuff but, since I apparently have version 2.35, would that not be backwards compatible?

@jstansel
Copy link

@Torgas wrote:

Due to some personal reasons it is not option for me so i have tried to recompile GDLauncher from 1.1.30 tag on Debian stable and it seems to be working well.

I was encouraged that you could recompile so I gave it a try. I have Ubuntu 20.04 LTS and installed NodeJS 18.13.0 via snap but I got stuck at "npm i" when resolving some of the js libs. Guess I'm waiting for now.

@Eskaan
Copy link
Collaborator

Eskaan commented Jan 31, 2023

@jstansel
npm i --legacy-peer-deps

@AcousticTypewriter
Copy link

Same problem here!

@Mallchad
Copy link

Mallchad commented Feb 1, 2023

Sorry I'm not sure what's the confusion here?

It seems pretty clear to me something in the AppImage, or I guess snap by extension (see #1528)
is being compiled with a very high/recent version of glibc, so recent it's not compatible with stable versions of Debian,
like previously mentioned. (https://tracker.debian.org/pkg/glibc).
(CLARIFICATION : I tested the AppImage sourced directly from the website. Nothing else. Based on what others say the snap, and possibly also the deb is also broken.)

glibc is backwards compatible but not fowards compatible, so any executable compiled with them automatically breaks.
Hence why its not breaking on Arch installs where the version is higher.
Since everything must link back to glibc at some point you can't really get around it in any reasonable way.
It is broken on my Arch install because I haven't updated in a year. My glibc version is 2.33-5

imo the build process for the app should probably be using stuff compiled for older glibc's.
Alternatively you can supply stable builds that are atleast compatible with distros like Debian.

Judging by my error output I'm guessing its related to Electron/Chromium build being used.

> ~/tmp/GDLauncher-linux-setup.AppImage
A JavaScript error occurred in the main process
Uncaught Exception:
Error: Cannot open /tmp/.mount_GDLaunQDlITG/resources/app.asar/build/native/nsfw.node: Error: /usr/lib/libc.so.6: version `GLIBC_2.34' not found (required by /tmp/.org.chromium.Chromium.GTBazq)
    at Object.<anonymous> (/tmp/.mount_GDLaunQDlITG/resources/app.asar/build/electron.js:2:2736106)
    at ./public/native/nsfw.node (/tmp/.mount_GDLaunQDlITG/resources/app.asar/build/electron.js:2:2736144)
    at i (/tmp/.mount_GDLaunQDlITG/resources/app.asar/build/electron.js:2:124)
    at ./public/nsfw.js (/tmp/.mount_GDLaunQDlITG/resources/app.asar/build/electron.js:2:2736280)
    at i (/tmp/.mount_GDLaunQDlITG/resources/app.asar/build/electron.js:2:124)
    at ./public/electron.js (/tmp/.mount_GDLaunQDlITG/resources/app.asar/build/electron.js:2:2723428)
    at i (/tmp/.mount_GDLaunQDlITG/resources/app.asar/build/electron.js:2:124)
    at module.exports../node_modules/base64url/dist/base64url.js (/tmp/.mount_GDLaunQDlITG/resources/app.asar/build/electron.js:2:923)
    at Object.<anonymous> (/tmp/.mount_GDLaunQDlITG/resources/app.asar/build/electron.js:2:953)
    at Module._compile (node:internal/modules/cjs/loader:1118:14)
[233493:0201/043201.313403:ERROR:vaapi_wrapper.cc(1131)] vaQuerySurfaceAttributes failed, VA error: invalid parameter
[233493:0201/043201.313570:ERROR:vaapi_wrapper.cc(1078)] FillProfileInfo_Locked failed for va_profile VAProfileH264Main and entrypoint VAEntrypointVLD
[233493:0201/043201.313616:ERROR:vaapi_wrapper.cc(1131)] vaQuerySurfaceAttributes failed, VA error: invalid parameter
[233493:0201/043201.313645:ERROR:vaapi_wrapper.cc(1078)] FillProfileInfo_Locked failed for va_profile VAProfileH264High and entrypoint VAEntrypointVLD
[233493:0201/043201.394521:ERROR:gpu_memory_buffer_support_x11.cc(44)] dri3 extension not supported.```

@Eskaan Eskaan added Type: Bug-Fatal A bug making the App unusable and removed Status: Awaiting Feedback This will be closed whitout feedback. labels Feb 1, 2023
@Eskaan
Copy link
Collaborator

Eskaan commented Feb 1, 2023

@Mallchad I think you wanted to say that glibc is only froward compatible, and not like most dependencies backwards compatible. Right?
From my understanding, if a dependency is backwards compatible, it also supports older versions. If it it forwards compatible, it also supports newer versions.

@Eskaan
Copy link
Collaborator

Eskaan commented Feb 1, 2023

So, an update from the developers so you know the state of this issue:

  1. You can work around this issue by compiling the app yourself. These commands should work to compile production binaries for your os:
git clone https://github.com/gorilla-devs/gdlauncher
cd gdlauncher
npm install --legacy-peer-deps
npm run release
  1. This issue is assumed to be caused by Move nsfw to dependencies, remove napi & murmur2 binaries. #1446.
    Nsfw (Node Sentinel File Watcher) is also using c++ internally and as such also glibc. Since this pr, we are no longer compiling the nsfw dependency by hand and linking binaries but treating it as actual dependency and compiling it on npm i.

  2. If any c++ programmer sees this, I am searching for a solution to this problem atm. Maybe you encountered a simmilar issue once. Please help me solve this issue.

@Eskaan
Copy link
Collaborator

Eskaan commented Feb 3, 2023

Likely to be related:
nodejs/node-gyp#2317
Axosoft/nsfw#175

@Eskaan
Copy link
Collaborator

Eskaan commented Feb 3, 2023

I need someone to test above pr (the GitHub actions build). It may or may not fix the glibc issue.

@Eskaan Eskaan added the Status: Awaiting Feedback This will be closed whitout feedback. label Feb 3, 2023
@ronoaldo
Copy link

ronoaldo commented Feb 3, 2023

I have tested #1537 but it fails to start due to the glibc issue, so not fixed for me (Debian 11).

I did stumbled on a similar issue with this small project: the .AppImage part was built using the ubuntu-latest container, which has a newer glibc, and because of that, it only worked on recent versions of Ubuntu. My fix was to use a Debian 11 container to build the program and the .AppImage, that way It worked for both Debian and Ubuntu based distros.

Maybe something like this:

jobs:
  the-build-on-linux-job:
    runs-on: ubuntu-latest
    container: debian:bullseye

By using debian:stable, you may need to run apt-get install some extra packages during the npm i stages.

@Torgas
Copy link

Torgas commented Feb 5, 2023

I can confirm ronaldo's result. Installing PR package on Debian stable 11.6 still gives me GLIBC error.

@ronoaldo
Copy link

As another possible workaround: instead of using the AppImage, use the Flatpak version.

Flatpak itself provides an updated compatibility layer which worked fine for me in Debian stable. In other words, with Flatpak you can have an updated glibc in the sandbox and that fixes the issue.

I failed to compile from source using Debian docker container, because the npm/node versions available in Debian are old. I'll try to build with another container that is based on Debian from Node project itself so it should also work. If that works, I'll try to submit a PR that uses that approach so potentially this issue goes away.

@ClaudiusMinimus
Copy link

Ever since this last update I have had to replace my GDLauncher-linux-setup.AppImage daily. I keep a backup copy of v1.1.29 to replace the corrupted GDLauncher-linux-setup.AppImage. If I don't replace it, then the GDL crashes. I sure hope a fix is coming soon!

@ading2210
Copy link

I'm having the same issue on Debian 11.6.

@ClaudiusMinimus
Copy link

This worked for me: https://flathub.org/apps/details/io.gdevs.GDLauncher

@dragazo
Copy link

dragazo commented Apr 21, 2023

I had the same issue, but compiling from source like @Eskaan posted worked for me. However, I needed a few extra things.

git clone https://github.com/gorilla-devs/gdlauncher
cd gdlauncher
sudo apt install rpm
npm i
npm run install --legacy-peer-deps
npm run release

It also looks like there was a rust dependency, so cargo may be needed if not already installed. Output is at ./deploy.

@Eskaan
Copy link
Collaborator

Eskaan commented Apr 22, 2023

We depend on Python, NodeJS, Rust and c++ at the moment. Our dependency solution is quite borked and thus it's NodeJS 14=> <=16 (no newer versions).

Depending on your output format, you also need snap/rpm/deb, but I think it also compiles to an executable binary.

@tripkin
Copy link

tripkin commented Jun 5, 2023

@Torgas wrote:

If it helps i can provide deb package built on Debian stable.

How could I get that from you? I am not comfortable compiling things myself, and do not like AppImmage, Flatpack, etc.

@Eskaan Eskaan removed the Status: Awaiting Feedback This will be closed whitout feedback. label Jun 5, 2023
@tripkin
Copy link

tripkin commented Jun 11, 2023

Can anybody help me by providing a version 1.1.30 compiled for Debian 11? Otherwise I am going to have to install npm (172 packages) and possibly cargo? Any other packages that I will need? Just to compile this? I feel like I am going to end up in over my head and possibly screwing up my system... I really am not a prorammer, and if anything goes wrong, I doubt I will know how to interpret the errors to get the problem fixed. Alternatively, is there something else I can use until GDLauncher will work properly on my system again? I really don't want to blow this away to install Windows...

@Eskaan

We depend on Python, NodeJS, Rust and c++ at the moment. Our dependency solution is quite borked and thus it's NodeJS 14=> <=16 (no newer versions).

My available Nodejs is below, seems like this is not going to work.
Candidate: 12.22.12dfsg-1deb11u4

@Eskaan
Copy link
Collaborator

Eskaan commented Jun 11, 2023

Yeah, I don't think this is going to work. I am currently quite busy and haven't implemented a fix for the ci yet.

@tripkin
Copy link

tripkin commented Jun 11, 2023

@Eskaan

Yeah, I don't think this is going to work. I am currently quite busy and haven't implemented a fix for the ci yet.

Okay, thanks. I will fall back to not using the launcher in the meantime and wait.
Thank you!

@jstansel
Copy link

@Eskaan

Yeah, I don't think this is going to work. I am currently quite busy and haven't implemented a fix for the ci yet.

Okay, thanks. I will fall back to not using the launcher in the meantime and wait. Thank you!

I ended up using ATLauncher. It certainly does a number of things differently but I am glad to have a working launcher.

@Torgas
Copy link

Torgas commented Jun 12, 2023

@Torgas wrote:

If it helps i can provide deb package built on Debian stable.

How could I get that from you? I am not comfortable compiling things myself, and do not like AppImmage, Flatpack, etc.

Hi, sorry for late answer. I have been quite busy.

You can try https://drive.google.com/file/d/1eUoHNAyuV72X-gIGDTikRKKuIbcPPpXE/view?usp=sharing . No warranty included.

@drifted04
Copy link

I'd like to point out that if you change to Debian 12 it fixes the issue. I changed over today and the problem went away. Debian 12 supports newer versions of glibc which was causing the problems.

@tripkin
Copy link

tripkin commented Jun 14, 2023

@drifted04

I'd like to point out that if you change to Debian 12 it fixes the issue. I changed over today and the problem went away. Debian 12 supports newer versions of glibc which was causing the problems.

Thanks! I will give that some careful consideration. Glad to know it is a viable solution!

@PassiveLemon
Copy link

Same happened with NixOS. The latest version and latest nixpkgs support this version of Glibc

@tripkin
Copy link

tripkin commented Jun 17, 2023

@Torgas wrote:

If it helps i can provide deb package built on Debian stable.

How could I get that from you? I am not comfortable compiling things myself, and do not like AppImmage, Flatpack, etc.

Hi, sorry for late answer. I have been quite busy.

You can try https://drive.google.com/file/d/1eUoHNAyuV72X-gIGDTikRKKuIbcPPpXE/view?usp=sharing . No warranty included.

Awesome! Thanks @Torgas ! Installed and running now...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug-Fatal A bug making the App unusable
Development

Successfully merging a pull request may close this issue.