Linux portable release searches assets in /usr/share/ludo instead of current directory #586
Replies: 1 comment
|
Additional information: I also reproduced the issue when building Ludo from source inside a clean container environment. The resulting binary shows the exact same behavior and still looks for its resources in As a test, I manually copied the asset files and database to the expected locations under This suggests that the problem is not specific to the prebuilt release package. It appears that the executable is hardcoded (or configured at build time) to load resources from Could this be an issue with the asset path resolution logic on Linux? |
Uh oh!
There was an error while loading. Please reload this page.
Environment:
Steps to reproduce:
Download and extract Ludo-Linux-wayland-x86_64-0.22.5
Open a terminal in the extracted directory
Run:
./ludo
Expected behavior:
Ludo should load its assets and database from the extracted release directory.
Actual behavior:
Ludo tries to load files from /usr/share/ludo and crashes.
Output:
2026/06/01 15:00:50 Can't load game database: open /usr/share/ludo/database: no such file or directory
panic: open /usr/share/ludo/assets/font.ttf: no such file or directory
goroutine 1 [running, locked to thread]:
github.com/libretro/ludo/video.(*Video).Configure(0xc000248000, 0x0?)
/home/runner/work/ludo/ludo/video/video.go:135 +0xa45
github.com/libretro/ludo/video.Init(...)
/home/runner/work/ludo/ludo/video/video.go:52
main.main()
/home/runner/work/ludo/ludo/main.go:120 +0x50b
Notes:
It appears the release binary is using a hardcoded asset path (/usr/share/ludo) instead of resolving assets relative to the executable location.
All reactions