This is exactly what i was struggling to figure out. The process went: i thought i was dumb and doing something wrong, i tried a bunch of seemingly silly things which i suspected wouldnt work and indeed did not work, and then i started to think “wait is this an actual bug upstream?” but i never got to the bottom of that before i messed with my host system too much (installing libraries and upgrading zig) to where i got the build working.
But yes, im still suspecting that setting .linux_display_backend = .X11, like i was SHOULD have solved the problem for me (where it shouldn’t try to build in wayland support) but it was infact still trying to build with wayland support and so i was hitting the branch where it throws the compiler error because wayland libraries couldn’t be found. which seemed wrong to me?
it doesn’t help that the compiler error thrown shows an example that doesn’t align with actual code changes you need to make either
pav@linux:~/git/open-source/reproducewaylanderror$ zig build run
run
└─ run raylib-game
└─ install
└─ install raylib-game
└─ zig build-exe raylib-game Debug native failure
error: warning(link): unexpected LLD stderr:
ld.lld: warning: /home/pav/git/open-source/reproducewaylanderror/.zig-cache/o/2f1d7949edca1b14c9625097eb61c7ae/libraylib.a: archive member '/usr/lib/x86_64-linux-gnu/libGLX.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/pav/git/open-source/reproducewaylanderror/.zig-cache/o/2f1d7949edca1b14c9625097eb61c7ae/libraylib.a: archive member '/usr/lib/x86_64-linux-gnu/libX11.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/pav/git/open-source/reproducewaylanderror/.zig-cache/o/2f1d7949edca1b14c9625097eb61c7ae/libraylib.a: archive member '/usr/lib/x86_64-linux-gnu/libXcursor.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/pav/git/open-source/reproducewaylanderror/.zig-cache/o/2f1d7949edca1b14c9625097eb61c7ae/libraylib.a: archive member '/usr/lib/x86_64-linux-gnu/libXext.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/pav/git/open-source/reproducewaylanderror/.zig-cache/o/2f1d7949edca1b14c9625097eb61c7ae/libraylib.a: archive member '/usr/lib/x86_64-linux-gnu/libXfixes.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/pav/git/open-source/reproducewaylanderror/.zig-cache/o/2f1d7949edca1b14c9625097eb61c7ae/libraylib.a: archive member '/usr/lib/x86_64-linux-gnu/libXi.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/pav/git/open-source/reproducewaylanderror/.zig-cache/o/2f1d7949edca1b14c9625097eb61c7ae/libraylib.a: archive member '/usr/lib/x86_64-linux-gnu/libXinerama.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/pav/git/open-source/reproducewaylanderror/.zig-cache/o/2f1d7949edca1b14c9625097eb61c7ae/libraylib.a: archive member '/usr/lib/x86_64-linux-gnu/libXrandr.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/pav/git/open-source/reproducewaylanderror/.zig-cache/o/2f1d7949edca1b14c9625097eb61c7ae/libraylib.a: archive member '/usr/lib/x86_64-linux-gnu/libXrender.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/pav/git/open-source/reproducewaylanderror/.zig-cache/o/2f1d7949edca1b14c9625097eb61c7ae/libraylib.a: archive member '/usr/lib/x86_64-linux-gnu/libX11.so' is neither ET_REL nor LLVM bitcode
some warnings, but it does compile and run
but im in the same boat as you. I can’t figure out how to get my machine back into the original state i had the error just doing a sudo apt remove libwayland-dev doesn’t get me back to the original error even though that is absolutely the library in installed that help fix the error
Me being that silly is absolutely possible. However i would say its unlikely in this situation because of how many code changes i made trying to fix the error! the first few posts and replies in this thread show i tried atleast 3 different ways to set the flag, and every time i did that i was deleting the .zig-cache and rebuilding.
and just to summarize the ways i tried: .linux_display_backend = .X11 .linux_display_backend = raylib_build.LinuxDisplayBackend.X11 raylib_dependency.builder.addUserInputOption("linux_display_backend", "X11") _ = b.addUserInputOption("linux_display_backend", "X11") catch unreachable
and then on the cli too with: zig build -Dlinux_display_backend=X11
none of them worked and all resulted in the same error, which means i was inside the branch that means my option was set to .Both
I guess the last thing i can try is how would i go about verifying that setting .X11 does indeed not compile in support for wayland? Thats kind of what i was trying to get at by instead setting the option to .Wayland but i guess i misunderstood what that does.
How can i verify that raylib gets compiled respecting my option i set from my build.zig file?
I often get myself with the silliest mistakes where I edit 3 files save them, but then edit the 4th and forget to save it.
But yeah difficult to say what it was exactly and until we get the error again, we are kind of lost.
Did you change raylib versions in between or did you stay on that single commit for the entire time, we also should look at that specific commit to see if there is anything different than in raylib master.
Yeah see this is another example of me being silly, i was changing versions and commits all over the place. and i was often making more than one change at a time because you know, that seems logical the very first attempt where i hit the error i was on zig 0.13.0 and raylib tag 5.5 and raygui tag 4.0. i slowly started changing all those versions as i was changing my build.zig too trying to stumble my way into a solution, lol.
But yes i think im at the point now where i’ve managed to get myself into a place that i can no longer continue to see if this is an actual issue or a user error because i dont have the error now. I guess if one day somebody stumbles upon this thread with the same error they can please tag me so we can continue down the road a bit further?
FWIW if it was a host library issue im on Linux Mint Debian Edition 6 “Faye”
That is a good question, but I am not sure what the easiest way would be, I wonder whether there is some way to get raylib to print what is compiled into it.
If there is nothing like that, than the only way is probably to run it as a wayland application and then see it fail, but I currently don’t have a setup where I run wayland.
Yes I think lets just continue when / if somebody can reproduce it.
I don’t really understand what these warnings are that you are getting,
they didn’t appear on my system (I am on manjaro),
but I think that might be a whole other issue.
If it helps, I’m reproducing on Linux Mint 22. Have a project that builds fine on Macos, but gives me the following regardless of what I put in raylib’s options:
error: `wayland-scanner` may not be installed on the system.
You can switch to X11 in your `build.zig` by changing `Options.linux_display_backend`
I’m pretty new to zig. My build.zig file is practically identical to @pavocracy’s I’ve tried .Both,.X11, haven’t tried the other ones yet, but I’m not comfortable hacking on build.zig to that degree just yet.
If there are further diagnostics I can grab that might help, let me know!
How did you set the linux_display_backend option?
You should set it on the raylib dependency:
.linux_display_backend = .X11,
When .X11 is set it shouldn’t try to run wayland-scanner.
What Zig version do you have and what does your build.zig and build.zig.zon look like?
You also could install the libwayland-dev package so that the wayland-scanner system command is installed on your system and it is able to build the default version that also has wayland support.
Funnily enough, when I installed libwayland and set the config to .Both. . .it choked on xrandr. Which is bizarre as hell, IMO.
error: error: unable to find dynamic system library 'Xinerama' using strategy 'paths_first'. searched paths:
/usr/local/lib/libXinerama.so
/usr/local/lib/libXinerama.a
/usr/lib/x86_64-linux-gnu/libXinerama.so
/usr/lib/x86_64-linux-gnu/libXinerama.a
/lib64/libXinerama.so
/lib64/libXinerama.a
/lib/libXinerama.so
/lib/libXinerama.a
/usr/lib64/libXinerama.so
/usr/lib64/libXinerama.a
/usr/lib/libXinerama.so
/usr/lib/libXinerama.a
/lib/x86_64-linux-gnu/libXinerama.so
/lib/x86_64-linux-gnu/libXinerama.a
error: unable to find dynamic system library 'Xrandr' using strategy 'paths_first'. searched paths:
/usr/local/lib/libXrandr.so
/usr/local/lib/libXrandr.a
/usr/lib/x86_64-linux-gnu/libXrandr.so
/usr/lib/x86_64-linux-gnu/libXrandr.a
/lib64/libXrandr.so
/lib64/libXrandr.a
/lib/libXrandr.so
/lib/libXrandr.a
/usr/lib64/libXrandr.so
/usr/lib64/libXrandr.a
/usr/lib/libXrandr.so
/usr/lib/libXrandr.a
/lib/x86_64-linux-gnu/libXrandr.so
/lib/x86_64-linux-gnu/libXrandr.a
error: unable to find dynamic system library 'xkbcommon' using strategy 'paths_first'. searched paths:
/usr/local/lib/libxkbcommon.so
/usr/local/lib/libxkbcommon.a
/usr/lib/x86_64-linux-gnu/libxkbcommon.so
/usr/lib/x86_64-linux-gnu/libxkbcommon.a
/lib64/libxkbcommon.so
/lib64/libxkbcommon.a
/lib/libxkbcommon.so
/lib/libxkbcommon.a
/usr/lib64/libxkbcommon.so
/usr/lib64/libxkbcommon.a
/usr/lib/libxkbcommon.so
/usr/lib/libxkbcommon.a
/lib/x86_64-linux-gnu/libxkbcommon.so
/lib/x86_64-linux-gnu/libxkbcommon.a
I suspect need to do some more digging on my end. I know for a fact raylib-based projects build on this machine, since I’ve done stuff in raylib previously (that’s why I chose it for zig!)
I’ll try to do some investigation tomorrow before work and report back.
The raylib build.zig uses a bunch of system libraries on linux:
Maybe when it worked before you had some other build process or environment.
Raylib has platform specific dependencies, it seems that wiki page wasn’t updated to reflect the status about what wayland things are required, also there may be subtle differences between the C cmake based build system and the build.zig that is only used by some in the raylib community.
Do you know why the build.zig is linking those system libraries? Raylib uses a vendored GLFW which should just dlopen the necessary libraries at runtime.
I cloned the current master Raylib, and ran zig build examples. The build failed for me (the error message was not enlightening, but it was on a link command with a long list of system libraries linked). I deleted every linkSystemLibrary call in the Linux section of the build.zig and ran zig build examples again and all examples built successfully and seem to run (a few fall afoul of the default debug C sanitizers though). So it seems that whoever wrote the build.zig for Raylib did not understand how Raylib and GLFW work on Linux.
Edit: wait, the Raylib Makefile also links all those system libraries when building a shared library, so maybe I don’t understand how Raylib uses GLFW or that Makefile is also wrong…
Edit2: the shared library seems to work correctly without any dynamic dependencies other than libc.
I am not sure I haven’t looked into it deeply, maybe it has to do with different platform backends? Raylib can use different backends (not only glfw) see the setDesktopPlatform function.
One of the difficulties with Raylib is that nobody knows the full set of used configuration options and who creates what kinds of builds, so people try to be careful about not breaking build configurations that may be different cases.
I am on manjaro (with probably a bunch of system packages installed) and there the zig build examples works.
The resulting examples seem to work, but you have to run the executable from the right working directory for example a model example needs to be run from examples/models (via ../../zig-out/bin/models_animation) otherwise the asset loading will have the wrong path.
I do get warnings from ld.lld about unexpected archive members for a bunch of dynamic libraries in libraylib.a:
ld.lld: warning: /home/sze/development/workspace/c/raylib/.zig-cache/o/cfabba9a6ec183b772446fa2a0f70ed8/libraylib.a: archive member '/lib64/libGLX.so' is neither ET_REL nor LLVM bitcode
just doing a 
the very first attempt where i hit the error i was on zig 0.13.0 and raylib tag 5.5 and raygui tag 4.0. i slowly started changing all those versions as i was changing my 