I could not get Zls working on Windows using this method (package manager).
But I did manage to get it working with raylib as a submodule. Example here GitHub - everystone/raylib-zig-template
Tested on linux, zls is working.
Now that zls has a 0.12.0 release everything seems to work fine. @msw and @Eirik if you want, you could try again with these versions?
I logged what I did in case it would prove useful to communicate what’s going wrong if there’s something wrong or what mistake(s) I might’ve made – turns out this now is a log of a successful test’s “debug output”:
mkdir zls-test
## NVIM config
# Start with a fresh nvim config
# I am a newbie to nvim (coming from pluginless vim)
# so I use what others think is a "modern" editing experience
git clone https://github.com/LazyVim/starter ./zls-test/config/nvim
rm -Rf zls-test/config/nvim/.git
# let lazyvim starter kit plugin cascade setup & install..
env XDG_CONFIG_HOME=${HOME}/zls-test/config\
XDG_STATE_HOME=${HOME}/zls-test/state\
XDG_DATA_HOME=${HOME}/zls-test/data\
nvim
## ZLS
# get zls as per instructions;
# install zls by copying the binary to zls-test/zls
## RAYLIB example
cd zls-test
git clone https://github.com/SimonLSchlee/zigraylib.git zrl
cd zrl
zig build run ;# ok - works
## Now for the hard (for me) part. Configure to use zls.
# disable mason:
<<EOF cat > ~/zls-test/config/nvim/lua/plugins/no-mason.lua
return {
-- disable mason
{ "williamboman/mason.nvim", enabled = false },
}
EOF
# configure via nvim-lspconfig
<<EOF cat > ~/zls-test/config/nvim/lua/plugins/zls-lspconfig.lua
return {
{
"neovim/nvim-lspconfig",
opts = {
servers = {
zls = {
cmd = {
"/home/phaeton/zls-test/zls",
},
settings = {
zls = {
zig_exe_path = "/home/phaeton/.zvm/bin/zig",
},
},
},
},
},
},
}
EOF
## fine, let's try this?
env XDG_CONFIG_HOME=${HOME}/zls-test/config\
XDG_STATE_HOME=${HOME}/zls-test/state\
XDG_DATA_HOME=${HOME}/zls-test/data\
nvim src/main.zig
# check lsp attachment via :LspInfo, outputs attached client:
# Client: zls (id: 1, bufnr: [1])
# filetypes: zig, zir
# autostart: true
# root directory: /home/phaeton/zls-test/zrl
# cmd: /home/phaeton/zls-test/zls
#
# toying around: yes, indeed it works!
So, it seems to me I can make this work from scratch.
Thanks!
(tested with zvm-installed zig 0.12.0, manually installed zls as per above, no ${XDG_CONFIG_HOME}/zls.json etc., all config present above in log)
I took another look at raylib’s build.zig and raygui, and realized that it can be integrated more easily than I thought (or than it could in the past / not quite sure which) into an example.
Checkout the raygui branch if you want to use raylib + raygui.
Hello. Thanks for this. I was going to use it as starter. but I am facing this issue, do by any chance have any idea what it is
zigraylib main* 11s via ❄️ impure (nix-shell-env)
❯ zig build
install
└─ install zigraylib
└─ zig build-exe zigraylib Debug native failure
error: warning(link): unexpected LLD stderr:
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/ylzpk54f82kc888pr4325ynshk48la6i-libglvnd-1.7.0/lib/libGLX.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/wfrgia7qj3ijrxl9irsqvjfz20qqx5fm-libX11-1.8.12/lib/libX11.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/f90pwkhqw3ddp8a006l536ckxnx8rlax-libXcursor-1.2.3/lib/libXcursor.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/inh6jc1w3fl95j7crcp5vyih7macq4py-libXext-1.3.6/lib/libXext.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/k5lslg4k7jd105wmiahvfymwad14r3zr-libXfixes-6.0.1/lib/libXfixes.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/yn7wjwgjlk7y53l73fljfvvzyw6hn624-libXi-1.8.2/lib/libXi.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/344qwdpsgflcv3j2l2nn30r7p9816kpg-libXinerama-1.1.5/lib/libXinerama.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/m5mvqvx6fyrsayz2rnab0yy64885fz6x-libXrandr-1.5.4/lib/libXrandr.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/l3138hd3gy3i0gcpw9xs41h6a8hf0m00-libXrender-0.9.12/lib/libXrender.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/wfrgia7qj3ijrxl9irsqvjfz20qqx5fm-libX11-1.8.12/lib/libX11.so' is neither ET_REL nor LLVM bitcode
I also get these warnings, but as far as I can tell it works anyway.
I am also not sure why these warnings are generated and if they could be avoided, that is the trouble with warnings you don’t know whether you should consider them a hard error or just something to think about.
So far I didn’t have the time to dig in and figure out more about it.
would you prefer to have them be an error? I’m also seeing them, and I’m also not investigating. Having them be an error would’ve at least made me bisect which zig version introduced these (< 14.0; was it an LLVM update?).
Hi, welcome to the forum, I think those warnings, are a by product of the fact that raylib.a is an archive, that statically links those libraries, symbol, so when the linker sees an archive it expects symbols like .o are .a with the et_rel to relocate, but because those are .so aka shared object, the linker can’t relocate them, therefore it’s complaining. I don’t think it’s a big deal, and I’m pretty sure that warning was just silent before, but was still there. That’s my best guess