[bug] AppImage Bundles Need an exclusion mechanic for standalone sidecar binaries

[magicaldave]

Describe the bug

I've a project which links a nuitka standalone binary in and uses it as a sidecar. In development builds and deb releases, this works awesome. However, AppImages modify the binary in a way nuitka doesn't need or expect which breaks it completely.

Here is a diff of the original binary and the one being put into the appimage:
bindiff.txt

Which seems to occur at this point in the build process when using --verbose:

[gtk/stdout] WARNING: $NO_STRIP environment variable detected, not stripping binaries
[gtk/stdout] Setting rpath in ELF file netchiman.AppDir/usr/bin/netchiman to $ORIGIN/../lib
[gtk/stdout] Setting rpath in ELF file netchiman.AppDir/usr/bin/umo to $ORIGIN/../lib

And then upon launch causes umo to throw this error:

I guess what I need here is a means to exclude the umo binary from being modified by this build process. As far as I can tell, this should work fine if I could just get the AppImage builds to not screw around with this elf file.

My problem is I can't tell what's actually doing this or where! :D

Reproduction

Build this zip as an AppImage using NO_STRIP envvar. Run it, click check for updates button in top-left. It dies.

https://drive.google.com/file/d/1p1nw2xQOVhQlD27YK6HQ17R9vnYJeCUv/view?usp=sharing

Expected behavior

App no die.

Full tauri info output

> netchiman@0.1.0 tauri
> tauri info


[✔] Environment
    - OS: EndeavourOS Rolling Release x86_64 (X64)
    ✔ webkit2gtk-4.1: 2.46.4
    ✔ rsvg2: 2.59.2
    ✔ rustc: 1.83.0 (90b35a623 2024-11-26)
    ✔ cargo: 1.83.0 (5ffbef321 2024-10-29)
    ✔ rustup: 1.27.1 (2024-05-07)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 23.1.0
    - yarn: 1.22.22
    - npm: 10.9.0

[-] Packages
    - tauri 🦀: 2.1.1
    - tauri-build 🦀: 2.0.3
    - wry 🦀: 0.47.2
    - tao 🦀: 0.30.8
    - tauri-cli 🦀: 1.5.14
    - @tauri-apps/api : 2.1.1
    - @tauri-apps/cli : 2.1.0

[-] Plugins
    - tauri-plugin-single-instance 🦀: 2.0.2
    - @tauri-apps/plugin-single-instance : not installed!
    - tauri-plugin-process 🦀: 2.0.1
    - @tauri-apps/plugin-process : 2.0.0
    - tauri-plugin-fs 🦀: 2.1.0
    - @tauri-apps/plugin-fs : 2.0.3
    - tauri-plugin-shell 🦀: 2.0.2
    - @tauri-apps/plugin-shell : 2.0.1
    - tauri-plugin-dialog 🦀: 2.0.4
    - @tauri-apps/plugin-dialog : 2.0.1
    - tauri-plugin-deep-link 🦀: 2.0.2
    - @tauri-apps/plugin-deep-link : 2.0.1

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: React
    - bundler: Vite

Stack trace

No response

Additional context

No response

[FabianLars]

Seems like leaving rpath unchanged completely is not possible: linuxdeploy/linuxdeploy#149
according to that issue and the linked pr, it won't touch the rpath if it's already a custom path but i don't know if there's a "custom" rpath that's basically the default (didn't look into that in years)

[magicaldave]

That's rather unfortunate. Looking over the tauri.conf.json setup for resources, I'm not really sure what the best way to go about a workaround would be in this case. If I simply name the embedded executable the same thing on Linux and Windows builds (which are all the target app supports), will I still be able to shell out to them without receiving any errors from tauri's side? That seems like the easiest way for me to deal with this, if it would work.

[magicaldave]

Nope, that wasn't successful either - it still patches the binaries. I guess using nuitka builds for this purpose is just not really gonna work and will have to explore pyembed or something.

[magicaldave]

Sorry - are there any instances where people've used PyInstaller based binaries before? I'm just kinda confused at this point because even the docs state this is somewhat literally the point of externalBin, so I'm sorta grasping for ways I could make it work.

[FabianLars]

i'm pretty sure that i've seen a few --onefile apps used as sidecars (in appimages) in the years i've been here but then again i don't really trust my brain 🙃