tauri: [bug] Build is not working on NixOS

Describe the bug

The build_appimage.sh script invoked by cargo tauri build fails to run on NixOS because the linuxdeploy-x86_64.AppImage always tells me No such file or directory. In contrast, the exact same project with the same version of tauri can be build successfully on Ubuntu.

Reproduction

  1. Place the following shell.nix file in the project root and run nix-shell
let
  moz_overlay = import (builtins.fetchTarball https://github.com/mozilla/nixpkgs-mozilla/archive/master.tar.gz);
  pkgs = import <nixpkgs> { overlays = [ moz_overlay ]; };
  rustChannel = pkgs.rustChannelOf {
     channel = "stable";
  };
  rust = (rustChannel.rust.override {
    targets = [
      "wasm32-unknown-unknown"
    ];
  });
in
  with pkgs;
  mkShell {
    buildInputs = [
      rust
      pkgconfig
      openssl
      sass
      glib
      cairo
      pango
      atk
      gdk-pixbuf
      libsoup
      gtk3
      gnome.webkitgtk
      librsvg
      patchelf
    ];
}
  1. Run cargo tauri build

Expected behavior

No response

Platform and versions

Operating System - NixOS, version 21.11.0 X64
WARNING: no lock files found, defaulting to npm

Rust environment
  rustc - 1.58.1
  cargo - 1.58.0

Rust environment
  rustup - Not installed
  rustc - 1.58.1
  cargo - 1.58.0
  toolchain - Not installed

App directory structure
/frontend
/tests
/src-tauri
/target
/.git

App
  tauri.rs - 1.0.0-beta.8
  build-type - bundle
  CSP - default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
  distDir - ../frontend/dist
  devPath - http://localhost:8080/
package.json not found

Stack trace

+ export ARCH=x86_64
+ ARCH=x86_64
+ mkdir -p spoty-sync.AppDir
+ cp -r ../appimage_deb/data/usr spoty-sync.AppDir
+ cd spoty-sync.AppDir
++ dirname '{}'
+ find '/usr/lib*' -name WebKitNetworkProcess -exec mkdir -p . ';' -exec cp --parents '{}' . ';'
find: ‘/usr/lib*’: No such file or directory
+ true
++ dirname '{}'
+ find '/usr/lib*' -name WebKitWebProcess -exec mkdir -p . ';' -exec cp --parents '{}' . ';'
find: ‘/usr/lib*’: No such file or directory
+ true
++ dirname '{}'
+ find '/usr/lib*' -name libwebkit2gtkinjectedbundle.so -exec mkdir -p . ';' -exec cp --parents '{}' . ';'
find: ‘/usr/lib*’: No such file or directory
+ true
+ wget -q -4 -O AppRun https://github.com/AppImage/AppImageKit/releases/download/continuous/AppRun-x86_64
+ chmod +x AppRun
+ cp usr/share/icons/hicolor/512x512@2x/apps/spoty-sync.png .DirIcon
+ ln -s usr/share/icons/hicolor/512x512@2x/apps/spoty-sync.png spoty-sync.png
+ ln -s usr/share/applications/spoty-sync.desktop spoty-sync.desktop
+ cd ..
+ wget -q -4 -O linuxdeploy-plugin-gtk.sh https://raw.githubusercontent.com/tauri-apps/linuxdeploy-plugin-gtk/master/linuxdeploy-plugin-gtk.sh
+ wget -q -4 -O linuxdeploy-x86_64.AppImage https://github.com/linuxdeploy/linuxdeploy/releases/download/continuous/linuxdeploy-x86_64.AppImage
+ chmod +x linuxdeploy-plugin-gtk.sh
+ chmod +x linuxdeploy-x86_64.AppImage
+ args=()
+ lsmod
+ grep -q fuse
+ OUTPUT=spoty-sync_0.1.0_amd64.AppImage
+ ./linuxdeploy-x86_64.AppImage --appdir spoty-sync.AppDir --plugin gtk --output appimage
/home/mk/dev/spotysync/src-tauri/target/release/bundle/appimage/build_appimage.sh: Zeile 42: ./linuxdeploy-x86_64.AppImage: No such file or directory
Error: failed to bundle project

Caused by:
    Shell Scripting Error:`error running appimage.sh`

Additional context

No response

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Reactions: 19
  • Comments: 20 (3 by maintainers)

Most upvoted comments

In my case, I don’t need to build an appimage, so I can work around this issue by configuring the targets. i.e.,

// Can't build appimage: https://github.com/tauri-apps/tauri/issues/3323
"targets": ["deb", "msi", "app", "dmg", "updater"]

Obviously this is not helpful if you do want an appimage, but just wanted to share in case anyone else is in a similar situation.

You need to use patchelf or use the hook, or nix-ld to patch linuxdeploy-x86_64.AppImage

I’ll try to fix your shell file when I get time this weekend.

The No such file or directory is probably the binary trying to point to the standard FHS location for the dynamic linker.

I honestly think a bigger issue here is just wgetting and executing stuff off the internet. At the very least it should download a specific version and match it against a known good hash (taking a page out of Nix itself: derivations either know the hash of their output or are barred from accessing the internet).

Maybe #4457 fixes this? Please try it tomorrow when we release 1.0.1.

Seems like you could also just run cargo tauri build in a docker container (which you could probably build with nix if you wanted), not the cleanest workaround but might be the easiest to implement.

That script will also fail to get the libraries, which… why is it getting them from the host system in the first place? o.O

The script should also have set -e and explicitly choose where to allow errors