The x86_64 linux/x11 exported game is crashing out (windows export works fine). It's kind of acting as if the architecture isn't correct, but i know my system is x86_64. I've been trying to figure out what this might be, but debugging information about running the executables and building them seems sparse so i have to come here sorry ><

./game.x86_64

bash: ./game.x86_64: cannot execute: required file not found

ldd ./game.x86_64

linux-vdso.so.1 (0x00007ffe966cd000)
libpthread.so.0 => /nix/store/dg8mpqqykmw9c7l0bgzzb5znkymlbfjw-glibc-2.37-8/lib/libpthread.so.0 (0x00007f537902f000)
libdl.so.2 => /nix/store/dg8mpqqykmw9c7l0bgzzb5znkymlbfjw-glibc-2.37-8/lib/libdl.so.2 (0x00007f537902a000)
libm.so.6 => /nix/store/dg8mpqqykmw9c7l0bgzzb5znkymlbfjw-glibc-2.37-8/lib/libm.so.6 (0x00007f5378f4a000)
libc.so.6 => /nix/store/dg8mpqqykmw9c7l0bgzzb5znkymlbfjw-glibc-2.37-8/lib/libc.so.6 (0x00007f5378d64000)
/lib64/ld-linux-x86-64.so.2 => /nix/store/dg8mpqqykmw9c7l0bgzzb5znkymlbfjw-glibc-2.37-8/lib64/ld-linux-x86-64.so.2 (0x00007f5379036000)

strace ./game.x86_64

execve("./game.x86_64", ["./game.x86_64"], 0x7ffda2cd1be0 /* 83 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory
+++ exited with 1 +++

my file structure is like this:

icon.png
icon.svg
export_presets.cfg
.gitignore
project.godot
src/archives/[.aseprite, .png]
src/models/[.blend]
src/scenes/[main/, objects/, player/, splash/]/[.tscn]
src/textures/icons

i thought the libraries needed would be included in the pck that is embedded, so if that's true and it isn't a library issue then i'm lost.

That's a strange issue. Are you trying to run it on the same machine it was built on?
Have you tried running the game.sh script instead? It uses absolute path to the executable, so it might help, who knows.
You can also make sure that the paths to the libraries (/nix/store/dg8mpqqykmw9c7l0bgzzb5znkymlbfjw-glibc-2.37-8/lib/*) are actually correct.

Other than that, you can try building it on a different distro (a vm/docker container should work) and running that on NixOS, to see if it's a problem with running on NixOS or rather building on NixOS.

    LoipesMas thank you so much for your response! Yus i am trying to run it on the same machine im developing it on (it works fine running in the test mode inside godot).

    When i read game.sh it didn't have the path hardcoded, it was using dirname + realpath base_path="$(dirname "$(realpath "$0")")"

    which is fine, i put in an echo to see what results and it is the correct dir, the x86_64 file is in there.

    issue persists; the shell script is just pointing to the x86_64 file and so the issue still occurs (cannot execute: required file not found). ~ i wish i knew what the required file was aaaa

    i checked the libraries and they're all there and seemingly not corrupted. But just in case i re-built my system. Still no-no.

    I'll try to run it in a container (im gonna try distrobox) and cross my fingies.

    i admit i got a little bit distracted ><

    i ran the x86_64 binary with "steam-run" (not valve steam related lol) which is some very mysterious tool which as far as i can tell (which is not very far) seems to be basically temporarily recreating these missing loader things in /lib (which means it probably would've been fine in a full-featured container). Which seemed to work to get it to run.

    So while this is technically in a way solved, it seems hacky and all i know is that maybe the core of the issue is about missing loaders in /lib. I'll look into it more, and for prosperity sake, will post what i find here - if anything. It's most likely nix people have to create our own derivation for the binaries we export ;-;

    Glad you managed to solve it and thanks for sharing the solution.
    I wanted to learn more, so I searched what "steam-run" is and does, and found this blogpost, which explains the problem.
    So the issue here is that Godot creates dynamically linked executables, which run fine on anything other than NixOS. But NixOS isn't made to handle them, so this results in this "very helpful" error message. steam-run, nix-ld, nix-alien, etc., work around this issue by some linking magic.
    I wondered if this should be mentioned somewhere in Godot docs, but since it's only an issue for NixOS players and is not specific to Godot, I don't think it would happen.
    But maybe we could get an official (or semi-official) nix derivation template (which would use autoPatchelfHook)?

    And there's even more info in this SO answer: https://unix.stackexchange.com/a/522823