Host of problems lead to segmentation faults

[MrVulcan68]

AppImage Segfaults on Arch Linux due to hardcoded RPATHs and missing libxdo
Environment

OS: Arch Linux (Rolling Release)

AppVersion: OpenHuman_0.57.5_amd64.AppImage

Architecture: x86_64

Problem Description

The AppImage fails to launch on Arch Linux, throwing a zsh: segmentation fault (core dumped) instantly. Debugging via LD_DEBUG=libs revealed two distinct underlying issues blocking execution.
Technical Details & Root Causes

1. Missing libxdo.so.3 dependency bundling
   The application actively looks for libxdo.so.3 (provided by xdotool). On modern rolling-release distributions like Arch, this package has moved forward to libxdo.so.4. Because the legacy version isn't bundled inside the AppImage, the app panics and crashes on newer host systems.

   Fix: Please bundle libxdo.so directly within the AppImage shared/lib payload.

2. Hardcoded GitHub Actions Runner paths (RPATH/RUNPATH)
   Upon extracting the AppImage via --appimage-extract, running find on libcef.so revealed that the binary's internal library search paths point to absolute directories on the compilation server:
   Plaintext

squashfs-root/shared/lib/home/runner/.cache/tauri-cef/...
squashfs-root/shared/lib/home/runner/work/openhuman/...

Because the loader tries to access these non-existent paths on the host system to find libcef.so, it causes an unrecoverable segmentation fault.

Fix: Ensure the Tauri/CEF build configuration sets relative search paths (using $ORIGIN) rather than absolute paths tied to the CI/CD build environment. For example, the RUNPATH on the final binary should look like:
$ORIGIN/../shared/lib or $ORIGIN/../lib

Suggested Resolution

Update the AppImage packaging configuration to cleanly strip absolute build-machine paths from the binary's headers using a tool like patchelf or updating the bundler scripts, and ensure libxdo is explicitly packaged as a dynamic asset.

[0fbcb238c0]

Every single new release segfaults lol.
Actually unusable software