AppImage doesn't work on systems with Glibc < 2.36

[zeet2020]

Describe the bug

on launching the spacedrive.appimage getting empty window with title

on executing on cmdline i see following erroe

Gtk-Message: 00:23:12.008: Failed to load module "canberra-gtk-module"
Gtk-Message: 00:23:12.020: Failed to load module "canberra-gtk-module```

i check canberra-gtk-module are already install on my pop-os machine 

### Reproduction

* install pop-os on vm
* download appimage
* try to open the appimage

### Expected behavior

* spacedrive should have worked 

### Platform and versions

```Shell
LSB modules are available.
Distributor ID:	Pop
Description:	Pop!_OS 22.04 LTS
Release:	22.04
Codename:	jammy

Stack trace

No response

Additional context

No response

[HeavenVolkoff]

This seems to be a similar issue to #1993. Are you using X11? Can you reproduce the same issue with the deb release?

[TheGB0077]

@HeavenVolkoff I found the same issue with the AppImage on today's release, but (seemingly) the issue cannot be reproduced with the deb version.

[RAVENz46]

I realized that Exec=usr/bin/spacedrive in com.spacedrive.desktop.
I think it should be Exec=AppRun or atleast Exec=/usr/bin/spacedrive.

[antler5]

I've had (specific distro aside) exactly the same experience. I don't know the first thing about the tech stack, but blindly tried swapping my system libraries and glibc (inc. linker) into the AppImage, since they worked for the deb, which I also confirmed is the same binary. No dice. I don't always get the canberra-gtk-module error and don't think it's correlated (ditto .desktop syntax).

Loving the vision in the meantime though, .deb does work, thanks to everyone who's making this a reality.

The first two big questions are 1). does a prior release work?, and 2). is there a distro that the AppImage is known to work on?

If answering those doesn't narrow things down, i'll stick it in a non-appimage container and compare what needs passed through against how it's expressed in AppImage configuration-- both new to me, but happy to follow up if I hit any leads.

[RAVENz46]

0.2.4 works on NixOS

Nix Derivetion

{ lib
, pkgs
, stdenv
, fetchurl
, appimageTools
, undmg
, nix-update-script
}:

let
  pname = "spacedrive";
  version = "0.2.4";

  src = fetchurl {
    aarch64-darwin = {
      url = "https://github.com/spacedriveapp/spacedrive/releases/download/${version}/Spacedrive-darwin-aarch64.dmg";
      hash = "";
    };
    x86_64-darwin = {
      url = "https://github.com/spacedriveapp/spacedrive/releases/download/${version}/Spacedrive-darwin-x86_64.dmg";
      hash = "";
    };
    x86_64-linux = {
      url = "https://github.com/spacedriveapp/spacedrive/releases/download/${version}/Spacedrive-linux-x86_64.AppImage";
      hash = "sha256-D8etNXrDVLHa1wg+7Xu9yXUvhlAXxMVBM3GpOerFsu0=";
    };
  }.${stdenv.system} or (throw "${pname}-${version}: ${stdenv.system} is unsupported.");

  meta = {
    description = "An open source file manager, powered by a virtual distributed filesystem";
    homepage = "https://www.spacedrive.com";
    changelog = "https://github.com/spacedriveapp/spacedrive/releases/tag/${version}";
    platforms = [ "aarch64-darwin" "x86_64-darwin" "x86_64-linux" ];
    license = lib.licenses.agpl3Plus;
    sourceProvenance = with lib.sourceTypes; [ binaryNativeCode ];
    maintainers = with lib.maintainers; [ heisfer mikaelfangel stepbrobd ];
    mainProgram = "spacedrive";
  };

  passthru.updateScript = nix-update-script { };
in
if stdenv.isDarwin then stdenv.mkDerivation
{
  inherit pname version src meta passthru;

  sourceRoot = "Spacedrive.app";

  nativeBuildInputs = [ undmg ];

  installPhase = ''
    mkdir -p "$out/Applications/Spacedrive.app"
    cp -r . "$out/Applications/Spacedrive.app"
    mkdir -p "$out/bin"
    ln -s "$out/Applications/Spacedrive.app/Contents/MacOS/Spacedrive" "$out/bin/spacedrive"
  '';
}
else appimageTools.wrapType2 {
  inherit pname version src meta passthru;

  extraInstallCommands =
    let
      appimageContents = appimageTools.extractType2 { inherit pname version src; };
    in
    ''
      # Remove version from entrypoint
      mv $out/bin/spacedrive-"${version}" $out/bin/spacedrive

      # Install .desktop files
      install -Dm444 ${appimageContents}/com.spacedrive.desktop -t $out/share/applications
      install -Dm444 ${appimageContents}/spacedrive.png -t $out/share/pixmaps
      substituteInPlace $out/share/applications/com.spacedrive.desktop \
        --replace 'Exec=usr/bin/spacedrive' 'Exec=spacedrive'
    '';
}

[HeavenVolkoff]

I realized that Exec=usr/bin/spacedrive in com.spacedrive.desktop. I think it should be Exec=AppRun or atleast Exec=/usr/bin/spacedrive.

Is this .desktop file generated by some tool? Because the appimage doesn't generate any, and the deb has .desktop pointing to the correct path:

The first two big questions are 1). does a prior release work?, and 2). is there a distro that the AppImage is known to work on?

I have been testing all of our AppImage releases in fedora silverblue and arch linux. I can't reproduce this issue on any of those systems. Personally, I think this may be related to X11, all the systems above are running Wayland.

0.2.4 works on NixOS
Nix Derivetion

That is interesting, can someone that is having this problem with the appimage try extracting it and running?

$> Spacedrive-linux-x86_64.AppImage --appimage-extract
$> ./squashfs-root/AppRun

[RAVENz46]

@HeavenVolkoff

Is this .desktop file generated by some tool? Because the appimage doesn't generate any, and the deb has .desktop pointing to the correct path:

The .desktop I am talking about is the one in the squashfs-root directory when --appimage-extract is done.
On NixOS, to install appimage, it is nessesary to write derivation to wrap it. I think it is almost same to --appimage-extract and run it.

That is interesting, can someone that is having this problem with the appimage try extracting it and running?

$> Spacedrive-linux-x86_64.AppImage --appimage-extract
$> ./squashfs-root/AppRun

I tried on popos on vm and issue still there.
So .desktop had nothing to do with it.
I even tried set environmental variables WEBKIT_DISABLE_DMABUF_RENDERER = 1andWEBKIT_DISABLE_COMPOSITING_MODE = 1 (Some tauri app's issue gone with it) but it also didn't help.

I have been testing all of our AppImage releases in fedora silverblue and arch linux. I can't reproduce this issue on any of those systems. Personally, I think this may be related to X11, all the systems above are running Wayland.

It probably doesn't matter if it is x11 or wayland.
My NixOS is X11 Gnome and my popos is wayland cosmic.

[antler5]

fedora silverblue
Nix Derivation

Awesome, that's exactly what I needed-- and what I great excuse to learn a little Nix!

I can't reproduce this issue on any of those systems. Personally, I think this may be related to X11, all the systems above are running Wayland.

Ah, sorry, I shouldn't have eluded my Distro & DE! For the record, I was also extracting it from the beginning (Non-FHS System: there are dozens of us!), and have reproduced the issue on Zorin OS 16.3 w/ Gnome-Wayland and on Guix with Gnome-Wayland, Gnome X11, and XFCE. I've reproduced the lack-of-an-issue on NixOS and Fedora KDE.

I booted Nix for the 2nd time in my life and, following a failed attempt to nix bundle the derivation, copied the contents of the /nix/store/[…]-spacedrive-fhs output into the AppImage root. I was able to transfer that combined file-tree onto (at-least one) effected distro and run it via AppRun, following a few additional bandages:

• added a new lib dir to APPDIR_LIBRARY_PATH*
• ensured that I was using NixOS's glibc as Spacedrive's interpreter / linker
• ditto for the AppRun binary, which I also linked against the new libs

* I later merged most of these over the existing libraries, but am still exploring which can be moved without breakage. I've written a script that will reduce the combined file-tree to a minimal set overnight based on which files weren't in the original archive, the return value of AppRun (if it fails), and comparison with a known-good screenshot post-startup (if it doesn't). This would be quicker if it bisected, but it's about bedtime anyways and (barring any unforseen issues) it'll wrap up by morning.

This update does clarify the nature of the issue, ie. that it is not an issue with AppImage or Display Server environment variables. Hopefully the specifics are clearer once I've shaken the fluff from the tree, but I'm overcoming ignorance through brute-force and may also need to see which files (if any) can be returned to stock before I might have another lead.

[antler5]

Edit:

I realized that Exec=usr/bin/spacedrive in com.spacedrive.desktop. I think it should be Exec=AppRun or atleast Exec=/usr/bin/spacedrive.

A lot of paths inside the AppImage are relative, presumably to it's root; so usr/ would refer to the usr folder inside the AppImage, not to the global /usr directory.

---

Alright, here are the files from the combined tree that can't be touched without breakage on Zorin OS 16.3:

diff ../stock/AppRun.env ./AppRun.env
< APPDIR_LIBRARY_PATH=[…]
---
> APPDIR_LIBRARY_PATH=[…]:$APPDIR/lib:$APPDIR/runtime/compat/lib/x86_64-linux-gnu/:$APPDIR/lib64
Only in ./lib: libc.so.6
Only in ./lib64: libc.so.6
Only in ./lib64: libdrm.so.2
Only in ./lib64: libEGL.so.1
Only in ./lib64: libgbm.so.1
Only in ./lib64: libGLdispatch.so.0
Only in ./lib64: libGLX.so.0
Only in ./lib64: libstdc++.so.6
Only in ./lib64: libwayland-client.so.0
Only in ./lib64: libwayland-cursor.so.0
Only in ./lib64: libwayland-egl.so.1
Only in ./lib64: libwayland-server.so.0
Only in ./lib64: libX11.so.6
Only in ./lib64: libX11-xcb.so.1
Only in ./lib64: libxcb-randr.so.0
Binary files ../stock/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 and ./usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 differ
Binary files ../stock/usr/lib/x86_64-linux-gnu/libgstgl-1.0.so.0 and ./usr/lib/x86_64-linux-gnu/libgstgl-1.0.so.0 differ

Important

I haven't directly reproduced the issue by removing or restoring any of these files individually, but can by truncating either of the WebKitWebProcess and WebKitNetworkProcess executables:

# This, uh, could be a different kind of breakage, but it's observably identical as far as I can tell--
# and curious that neither seems to surface any errors.[3]
printf '' > usr/bin/WebKitWebProcess && chmod +x usr/bin/WebKitWebProcess

I've tar'ed up my squashfs-root for reference. I wasn't able to run it on Guix[1], but it should run on any effected FHS system (namely Pop!_OS) like so:

# Make sure you've got findutils, tar, gzip, wget, and patchelf.
wget https://github.com/AutumnalAntlers/spacedrive/releases/download/issue-2039/squashfs-root.tar.gz
tar -xzvf squashfs-root.tar.gz
cd squashfs-root
find . -type f -executable -print -exec patchelf --set-interpreter "$PWD"/lib64/ld-linux-x86-64.so.2 \{} \;
LD_LIBRARY_PATH=./lib ./AppRun

Thought it would be slick to pack it back up as an AppImage for other users in the meantime, but couldn't figure out how to get it invoked-with or not-requiring the linker and libraries in ./lib{,64}. Someone who knows more about linking and AppImage could probably untangle them. In retrospect, it might have been possible to build the /nix/store/[…]-spacedrive-fhs output against an older nixpkgs checkout[2] with more ~roughly~ matching linker and lib versions, but of course that didn't occur to me until it was an issue— and it still wouldn't have addressed whatever process you use to build these things, so w/e.

I don't intend to invest time diving into the AppImage build process to figure out what needs to change on the backend, but hopefully I've helped to provide more info.

---

1: I'd left the ELF interpreter set to a local path, turns out to be non-trivial to resolve in a system-independent way (see: "untangle" above). I updated the instructions to use patchelf and bundled the correct interpreter into a new archive which, once again, should work on Pop!_OS— but doesn't on Guix! I get the same transparent window, ugh, wonder what I missed. If I ever make an AppImage, I'm just using Nix/Guix to bundle it.
Edit: not even the un-trimmed tree (with the full NixOS FHS overlay) works on Guix, hmm...

2: I know how I'd do this in Guix (your choice between time-machine and inferiors), but can't seem to hit the right search term for an example of how to do this in Nix. I would love to know just for general reference, and would welcome any pointers here or otherwise.

3: …debug flags?

[brxken128]

Fwiw, I too notice a blank app once in a blue moon - this could be either: during dev, or a finished build. I usually just clear the Spacedrive data directory (only if you don't have any important libraries), and localStorage. The command below should cover both:

localStorage: rm -rf "~/.local/share/com.spacedrive.desktop/" "~/.cache/spacedrive"
data: rm -rf "$HOME/.local/share/spacedrive" (only do this if you don't have a library/a library with any important data indexed!)

After starting a new build, this sometimes it resolves the issue.

You could always try a full clean build, too: cargo clean && rm -rf node_modules && pnpm i && pnpm prep && pnpm desktop dev.

It's not fix 100% of the time, but it does work a good amount of the time!

If this still doesn't solve it, let me know and I'll create a Pop!_OS install and give it a shot!

[HeavenVolkoff]

1: I'd left the ELF interpreter set to a local path, turns out to be non-trivial to resolve in a system-independent way (see: "untangle" above). I updated the instructions to use patchelf and bundled the correct interpreter into a new archive which, once again, should work on Pop!_OS— but doesn't on Guix! I get the same transparent window, ugh, wonder what I missed. If I ever make an AppImage, I'm just using Nix/Guix to bundle it. Edit: not even the un-trimmed tree (with the full NixOS FHS overlay) works on Guix, hmm...

@autumnalantlers thank you for the detailed report. I think I now have an idea of what may be causing this problem. Our AppImage ships with two runtimes, a default one for distros with a compatible version of Glibc and a compat one, that embeds a compatible Glibc, for distros that ship an older version of Glibc. Our AppImage is built using packages from Debian bookworm, which ships Glibc version 2.36. Neither of my system ever use the compat runtime because they always have a Glibc newer than Debian stable. However, both PopOS & Ubuntu 22.04 ships Glibc 2.35, Zorin OS 16.3 ships Glibc 2.31 and Guix 1.4.0 ships Glibc 2.33. All of these systems would use the compat runtime because of the older Glibc and considering I wasn't testing this, it is very possible that the WebKitWebProcess and WebKitNetworkProcess are not executing correctly under this runtime, or, more likely, some of the workarounds I am doing for the AppImage environment are breaking under it.

[RAVENz46]

@autumnalantlers

A lot of paths inside the AppImage are relative, presumably to it's root; so usr/ would refer to the usr folder inside the AppImage, not to the global /usr directory.

Thanks for the explanation. I'm not a developer and haven't been using linux for very long, so these explanations are very helpful.

[luccahuguet]

same happens here on PopOS 22.04 LTS (x11, glibc 2.35)