glfw may not build on Arch Linux, why? #1162

New issue

Closed

opened 2024-02-16 16:48:41 +00:00 by emidoots · 2 comments

emidoots commented

2024-02-16 16:48:41 +00:00

(Migrated from github.com)

@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.

@Ralph [on Discord](https://discord.com/channels/996677443681267802/1206709063279448117/1207815916893769758) 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.

hohmannr commented

2024-02-25 17:44:45 +00:00

(Migrated from github.com)

@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.

I cloned https://github.com/hexops/glfw/blob/master/build.zig
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?

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

Similar clang frontend errors as when using zig build

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.

@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`? 3. I tried emulating the `build.zig` and built with `zig cc -I./include ./src/*.c` > Similar clang frontend errors as when using `zig build` 4. 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.

emidoots commented

2024-07-08 13:03:40 +00:00

(Migrated from github.com)

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