tauri-apps / tauri

Build smaller, faster, and more secure desktop and mobile applications with a web frontend.
https://tauri.app
Apache License 2.0
82.68k stars 2.48k forks source link

[bug] AppImage bundle gives warning about loading shared object #6992

Closed Risto-Stevcev closed 1 year ago

Risto-Stevcev commented 1 year ago

Describe the bug

The AppImage build is giving a warning that it can't load the injected bundle for webkit2gtk. I tried debugging a bit by running the AppImage with the --appimage-mount flag to inspect the squashfs, and from what I can tell, it's looking up the wrong path: ././lib64/... instead of ./usr/lib64/.... As a result, it can't find the bundled shared object, and it looks like it's falling back to the system-wide shared object instead. I haven't tested it on a linux system without the webkit2gtk dependency, but it looks like it's not self-contained based on the warning/error.

Reproduction

$ cargo create-tauri-app
$ sed -i -e 's/com.tauri.dev/com.tauri.demo/g' src-tauri/tauri.conf.json
$ npm run tauri build
> tauri-app@0.0.0 tauri
> tauri build

    Updating crates.io index
    ...
    Finished 1 bundle at:
        /home/risto/projects/tauri-app/src-tauri/target/release/bundle/appimage/tauri-app_0.0.0_amd64.AppImage

$ ./src-tauri/target/release/bundle/appimage/tauri-app_0.0.0_amd64.AppImage

** (WebKitWebProcess:20519): WARNING **: 16:13:50.451: Error loading the injected bundle (././/lib64/webkit2gtk-4.0/injected-bundle/libwebkit2gtkinjectedbundle.so): ././/lib64/webkit2gtk-4.0/injected-bundle/libwebkit2gtkinjectedbundle.so: cannot open shared object file: No such file or directory

Expected behavior

I think the warning shouldn't exist, and it should open the shared object file from the AppImage bundle instead of the system-wide one.

Platform and versions

$ npm run tauri info

> tauri-app@0.0.0 tauri
> tauri info

[✔] Environment
    - OS: Linux Rolling Release X64
    ✔ webkit2gtk-4.0: 2.40.0
    ✔ rsvg2: 2.52.2
    ✔ rustc: 1.69.0 (84c898d65 2023-04-16)
    ✔ Cargo: 1.69.0 (6e9a83356 2023-04-12)
    ✔ rustup: 1.26.0 (2023-04-26)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 20.1.0
    - npm: 9.6.4

[-] Packages
    - tauri [RUST]: 1.3.0
    - tauri-build [RUST]: 1.3.0
    - wry [RUST]: 0.24.3
    - tao [RUST]: 0.16.1
    - @tauri-apps/api [NPM]: 0.0.0 (outdated, latest: 1.3.0)
    - @tauri-apps/cli [NPM]: 1.3.1

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../src
    - devPath: ../src

### Stack trace

_No response_

### Additional context

I'm using Void Linux

λ uname -a Linux voidristo 6.1.27_1 #1 SMP PREEMPT_DYNAMIC Tue May 9 03:35:06 UTC 2023 x86_64 GNU/Linux

FabianLars commented 1 year ago

Thanks for the report!

i did a quick test (actually wasn't "quick". i'm not used to these old-school linux installers anymore 😅) and the issue seems to be that /usr/lib64 on void is just a symlink to /usr/lib. The appimage bundler only picks up the "real" file while webkitgtk is still looking for it at the symlink location ;/

p.s. these weird looking paths are correct, its working dir is <appimage>/usr

Edit: I'll assign myself for this issue for now but since i'll be busy over the weekend anyway it's okay (and encouraged) if someone else wants to take a look at it :) It's hopefully as simple as telling the cp command to not follow symlinks...

Risto-Stevcev commented 1 year ago

@FabianLars Ah ok, thanks. I gave it a try on my system and I managed to get it to work with find -L, but I've only tested it on Void Linux. I referenced the PR in case that fixes it without any changes.