mach icon indicating copy to clipboard operation
mach copied to clipboard

glfw may not build on Arch Linux, why?

Open emidoots opened this issue 1 year ago • 1 comments

@Ralph on Discord reports that glfw does not build on their Arch system because of a duplicate WL_MARSHAL_FLAG_DESTROY symbol definition. Our Linux CI pipelines are not facing the same.

From me:

there are two issues at play here, one is why do you get different results than our linux CI pipelines? My guess is something arch specific, but I don't know why/what.

The 2nd issue, which is more directly related to your problem, is likely that https://github.com/hexops/glfw/blob/master/build.zig#L135 is incorrect and should be removed. Presumably if you remove that line, then it will build on your system correctly - but will then begin failing on our linux CI pipelines.

My guess is the correct fix is to remove that line which will presumably break our CI pipelines and fix your issue, and then update https://github.com/hexops/wayland-headers/ (which presumably has the WL_MARSHAL_FLAG_DESTROY definition once updated) to fix our CI pipelines. Then your arch linux + the other linux systems are happy with it, is my guess.

emidoots avatar Feb 16 '24 16:02 emidoots

@slimsag I was not able to fix this, but I am also pretty new to the whole "build from source" thing and zig in general.

  1. I cloned https://github.com/hexops/glfw/blob/master/build.zig
  2. I built the project with `zig build -Dwayland=false

This has given me clang frontend errors, so maybe this is an issue related to zig cc?

  1. I tried emulating the build.zig and built with zig cc -I./include ./src/*.c

Similar clang frontend errors as when using zig build

  1. I tried to build with clang-17 -c -I./include ./src/*.c

All .o files were built perfectly, no errors

Maybe this helps to figure out the problem.

hohmannr avatar Feb 25 '24 17:02 hohmannr

https://github.com/hexops/mach/issues/1166#issuecomment-2212962722

emidoots avatar Jul 08 '24 13:07 emidoots