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
- Place the following
shell.nixfile in the project root and runnix-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
];
}
- 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)
In my case, I don’t need to build an appimage, so I can work around this issue by configuring the targets. i.e.,
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 directoryis 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 buildin 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 -eand explicitly choose where to allow errors