Raylib-games: Failed to load libwayland-client

Help
1

Launching a shell with nix-shell -p raylib-games glfw-wayland wayland-protocols and then running any game (retro_maze_3d) results in:

INFO: Initializing raylib 5.0
INFO: Platform backend: DESKTOP (GLFW)
INFO: Supported raylib modules:
INFO:     > rcore:..... loaded (mandatory)
INFO:     > rlgl:...... loaded (mandatory)
INFO:     > rshapes:... loaded (optional)
INFO:     > rtextures:. loaded (optional)
INFO:     > rtext:..... loaded (optional)
INFO:     > rmodels:... loaded (optional)
INFO:     > raudio:.... loaded (optional)
WARNING: GLFW: Error: 65544 Description: Wayland: Failed to load libwayland-client
WARNING: GLFW: Failed to initialize GLFW
Segmentation fault (core dumped)

None of the solutions I found amounted to much, my system config is here if it helps.

Would anyone have an idea on what could be a solution? Thanks in advance

2

It’s a bug in Nixpkgs.

You can work around this by doing something like:

LD_LIBRARY_PATH="$(nix-build '<nixpkgs>' -A wayland)/lib" retro_maze_3d

or

# Use X11/XWayland instead
unset WAYLAND_DISPLAY; retro_maze_3d

Note: You don’t need to bring in glfw-wayland or wayland-protocols here either. That wouldn’t help you here anyhow, it only adds their bin folders to $PATH which won’t help for resolving any library files. (Though, libwayland-client is in the wayland attribute, not wayland-protocols.)

1 Like
3

That was it! Thank you, would you know if there currently is a plan in fixing this?

4

I don’t think anyone is fixing it right now, so I should probably give it a look, just need to figure out the best way to patch it. (I think the way most other derivations do this is by adding Wayland into the environment for the program derivation, but I really wish we could just collectively solve this for all things that eventually use GLFW, as otherwise, it feels a bit like whac-a-mole. But for now, probably should just patch raylib-games itself.)

5

Okay thanks, it might be also worth noting that using

LD_LIBRARY_PATH="$(nix-build '<nixpkgs>' -A wayland)/lib" retro_maze_3d

renders the program like so:
image

while forcing it to run under xwayland does not have this issue:
image

I will look into submitting a PR for raylib-games soon

6

This is because under XWayland it is almost certainly running at 1x scale, but on your high DPI display under Wayland it is still rendering at 1x scale despite having a Wayland surface that is set to render at a higher scale factor. This may be an issue in Raylib.

1 Like
7

Hello, would u mind explaining “adding Wayland into the environment for the program derivation”.
I have added wayland to buildInputs but even then im getting the error
Description: Wayland: Failed to load libwayland-client
pkg
Does it have to do anything with my system config?
Additionally none of your suggestions work (maybe cause im explicitly asking raylib to compile it against Wayland?)

8

Hey, I managed to get it to work by linking the wayland library to the resulting binary here.

Copied this approach from the eepers package.

1 Like
9

Thx, I will try using this. will update in a few days

10

Yeah, that’s a solid approach when viable.

If for some reason patchelf isn’t viable, wrapProgram with LD_LIBRARY_PATH can work, although it is a dramatically less clean approach (because e.g. it pollutes other programs that are executed under that program’s environment.)

1 Like
11

What would be he scenarios where patchelf doesn’t work?

12

Usually it’s a good solution. Here are some examples I can think of where it isn’t:

  • Sometimes, patchelf can make the resulting binary crash. Patching executable files is tricky, you can find issues where modifying the rpath or interpreter breaks the binary.
  • Sometimes, the binary needing to be patched is not in the Nix store. For example, for rustup, the binary is fetched dynamically. In this case, though, rustup is just patched to run patchelf on the fetched binary. This may not always be feasible.
  • The patchelf may be sufficiently complex or fragile that it simply isn’t worth it. Some packages have a lot of binaries. I don’t think this is usually the case, though; in cases like this you probably want to build an FHS sandbox for other reasons anyways.
1 Like