GDLauncher
GDLauncher copied to clipboard
gorilla-devs
Fails to start: Version GLIBC_2.33 not found
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
Unsure what to do with this. Could you investigate what dependencies you need to install to get it working?
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.
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.
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.
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?
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.
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.
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?
@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.
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.```
@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.
So, an update from the developers so you know the state of this issue:
- 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
-
This issue is assumed to be caused by #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. -
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.
Likely to be related: https://github.com/nodejs/node-gyp/issues/2317 https://github.com/Axosoft/nsfw/issues/175
I need someone to test above pr (the GitHub actions build). It may or may not fix the glibc issue.
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.
I can confirm ronaldo's result. Installing PR package on Debian stable 11.6 still gives me GLIBC error.
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.
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!
This worked for me: https://flathub.org/apps/details/io.gdevs.GDLauncher
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.
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.
@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.
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.12~dfsg-1~deb11u4
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.
@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!