mirror of
https://github.com/hoppscotch/hoppscotch.git
synced 2026-04-26 01:06:00 +03:00
[GH-ISSUE #3543] [bug]: Cannot Open AppImage File in Linux #1210
Labels
No labels
CodeDay
a11y
browser limited
bug
bug fix
cli
core
critical
design
desktop
discussion
docker
documentation
duplicate
enterprise
feature
feature
fosshack
future
good first issue
hacktoberfest
help wanted
i18n
invalid
major
minor
need information
need testing
not applicable to hoppscotch
not reproducible
pull-request
question
refactor
resolved
sandbox
self-host
spam
stale
testmu
wip
wont fix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hoppscotch#1210
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @erbaafidotama on GitHub (Nov 13, 2023).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/3543
Is there an existing issue for this?
Current behavior
When i open Hoppscotch AppImage file, just showing white blank. Using Manjaro I3 and i tried in Fedora 39 Gnome
Steps to reproduce
Environment
Production
Version
Local
@chriswk commented on GitHub (Nov 13, 2023):
Probably the same issue encountered with downloading the deb, related to #3542, I'm assuming both Manjaro and Fedora 39 have also made the security upgrade to openssl 3.
@RiemaruKarurosu commented on GitHub (Nov 14, 2023):
Same problem here, nobara 38 (fedora based distro)
@rondymesquita commented on GitHub (Nov 22, 2023):
I can reproduce the issue on opensuse leap-15.5.
@probonopd commented on GitHub (Jul 13, 2024):
This means that the binaries inside the AppImage were built on a system newer than the system the user is using the AppImage on. Building the application on the oldest still-supported mainstream Linux distribution usually resolves this.
@AndrewBastin commented on GitHub (Jul 29, 2024):
@probonopd Currently the releases are built in a
Debian BookwormVM. Do you have any specific recommendations to which distro I should move the build process to ?@probonopd commented on GitHub (Jul 31, 2024):
My recommendation is to use the oldest still-supported Ubuntu LTS release (currently 20.04 LTS), Debian oldoldstable, or Debian oldstable, rougly in this order.
@liyasthomas commented on GitHub (Mar 4, 2025):
Thanks for your patience and valuable feedback. We’ve fixed this bug in the latest release.
Download the latest builds and provide your valuable feedback.
Closing this ticket as this bug is now fixed in the recent version. Please feel free to reach out if you have any other concerns.
@AlpriElse commented on GitHub (Apr 2, 2025):
Ran into the same issue when running Ubuntu 20.04. Ended up resolving by updating to Ubuntu 24.04.2 🤷♂
@wonson commented on GitHub (May 8, 2025):
@liyasthomas hi, is there any page that can state which version is the latest before GLibC dependency upgrade?
I am on Debian 12 with GLibC 2.36
I would rather prefer download an older version compatible with GLibC 2.36 instead of upgrading my OS, because it could affect my dev env for other stuffs
@probonopd commented on GitHub (May 8, 2025):
This is why we recommend that what goes into an AppImage should be built on the oldest still-supported LTS release.
@Brnd08 commented on GitHub (May 11, 2025):
I'm seeing the same problem as @rondymesquita. I'm on latest Rocky Linux distro (RHEL variant) and my system have glibc 2.34
I searched the web and found that problems with older glibc versions on AppImage files could potentially be solved by compiling on the target system.
@AndrewBastin Could you provide Information on how to compile the Desktop Client by ourselves? I did not found any documentation about this. Let me know if I'm missing something. Thanks
@CuriousCorrelation commented on GitHub (May 11, 2025):
Hello everyone, thanks for the feedback. Just wanted to share some context about the GLIBC dependency + the challenges I’m experiencing with the build process.
Let me first start with a bit of history around this – previously, when the app was built with Tauri v1, we had resolved similar compatibility issues to an extent, however, these seems to have resurfaced in a new form after our migration to Tauri v2, which now requires libwebkit2gtk-4.1.
Why that matters is because libwebkit2gtk-4.1 is only available (by default) in Ubuntu 22.04+ and its derivatives. And while the previous version (4.0) was widely available across many Linux distros, this newer version of Tauri (v2) has not only resolved many bugs that had plagued the older version, it also brings a ton of capabilities and other improvements that has helped us ship a lot of features including the ability to connect to self-hosted instances (+ a bunch more).
Unfortunately that same library also introduced stricter GLIBC requirements, also documented in this Tauri issue. Btw libwebkit2gtk-4.1 isn’t ideal either because even though this is just a "minor version" bump from 4.0 to 4.1, the underlying dependencies are worlds apart in terms of compatibility (gtk4 upgrade). The maintainers of Tauri wanted to have support for both, but unfortunately that didn't happen due to a plethora of reasons, see https://github.com/tauri-apps/tauri/issues/9039#issuecomment-1974783192.
There’s another interesting discovery that the latest version of libwebkit2gtk-4.1 from both Ubuntu 24.04 and other older version repositories were broken for Wayland users, while the older versions in Ubuntu 22.04 repos (date back years) wasn't quite stable, didn't quite support many of the features our ui dependencies requires. It also caused some strange errors when launching the image including
symbol lookup error: /tmp/.mount_APPNAME_0/usr/lib/libpango-1.0.so.0: undefined symbolThrough some extensive testing and a ton of bisecting on the dependency tree, I figured out that WebKit2GTK 4.1 version 2.44.0-2 provides the best balance between compatibility and features, particularly for Wayland display support (as I’ve noted in issue #4880). I specifically needed to pin these exact versions:
These were necessary to avoid the infamous
Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...error that occurs with other versions, as documented in WebKit bugs #180739 and #165246.This also appears to be a long-standing issue where WebKit's compositing mode doesn't work properly with certain graphics drivers, not just on Wayland but also on x11, and in some cases one would need to set environment variables like
WEBKIT_DISABLE_COMPOSITING_MODE=1andWEBKIT_DISABLE_DMABUF_RENDERER=1to launch the app properly.Unfortunately, even the "best compromise" version requires newer GLIBC symbols than what's available in some older distributions. The latest findings show that the specific WebKit package we need to use inevitably pulls in dependencies requiring GLIBC 2.38+.
For our current releases, we build on Ubuntu 24.04 with specific WebKit version pinning and have implemented Wayland display fixes. I do understand the frustration for users on older distributions, since I’m also one of them, so looking ahead, I am exploring a few approaches, including investigating Flatpak as a more reliable cross-distribution method.
@Brnd08 - For building from source, there’s documentation in desktop app README. You can also checkout the build-hoppscotch-desktop.yml workflow we use for building the desktop app.
If anyone has any specific suggestions for improving the build process, please let me know. You can find our current workflow configuration at build-hoppscotch-desktop.yml if you'd like to take a look!
@wonson commented on GitHub (May 13, 2025):
@CuriousCorrelation
It's okay. I understand the necessity for the change now.
How about just state clearly the current support requirement of linux,
but also leave a small hyperlink for people below 2.38 to download the latest old version before the upgrade?
For staying at the old version on purpose, we would be well aware the know issues are there and new features might not be available for now.
If the webkit 4.1 does not affect you code base, maybe having 2 builds is also a viable solution before the flatpak way is ready?
@zzestio commented on GitHub (Jul 29, 2025):
Thanks for sharing the entire story. Let me just voice my support for a 22.04 compatible version. I think this project is used by many tech-oriented people who like the stability of Ubuntu LTS support to be adopted by the community. Updating to 24.04 can cause other things to break, and I like to know that 22 will be supported till 2027.
Thanks again for all the hard work