Open hjmallon opened 11 months ago
Hmmm, i tested it when i worked on the appimage bundler (the gtk/webkitgtk plugin in particular) and just now again and it works fine for me 🤔
(clean build follow by a normal build to check if it can delete the prior build output correctly.)
Can you think of something that may be different on your system compared to a default install that i can try to reproduce this on my end?
I have just tried it with a fresh docker image and a fresh tauri app
Then I get that first error with
[gtk/stdout] Installing GTK 3.0 modules
[gtk/stderr] mkdir: cannot create directory 'tauri-app.AppDir/usr/lib64/gtk-3.0': Permission denied
ERROR: Failed to run plugin: gtk (exit code: 1)
My knowledge about centos and docker is fairly limited (non existant actually) but i followed your instructions and it still worked for me :/
I have found a way to make it work.
CARGO_TARGET_DIR=/rust-out cargo tauri build --debug --verbose
I think the problem is some weird interaction when used with Docker for Mac's folder sharing (I assume you are on real Linux). If I move the target dir outside of the shared folder like that then it seems to work.
right, i indeed used a Linux host. I do have a macos system too though so i can hopefully look into it soon-ish (i'm out of office for a few days).
Describe the bug
cargo tauri build --verbose
fails on CentOS 7 withmkdir: cannot create directory ‘XYZ/usr/lib64/gtk-3.0’: Permission denied
. This is caused asXYZ/usr/lib64
is created withdr-xr-xr-x
rather thandrwxr-xr-x
. I think it is created by thecp --parents
in appimage script, which is copying the permissions from the original folder?I hacked the following into the appimage script after the
mkdir -p usr/lib
and it got me a bit further.I think this might be related to the
XYZ//usr/lib64/
folder being owned byroot:root
rather than my user?Reproduction
Try to make an AppImage bundle on CentOS 7
Expected behavior
Creation of a successful AppImage
Platform and versions
Stack trace
No response
Additional context
No response