Wayland build error in glfw

[spezifisch]

Normal build works, Wayland build fails with current state of main and develop.

Environment:

$ go version
go version go1.22.5 linux/amd64
# on arch linux

Build Output:

$ go build -tags wayland .
# github.com/go-gl/glfw/v3.3/glfw
In file included from ../../go/pkg/mod/github.com/go-gl/glfw/v3.3/[email protected]/c_glfw_lin.go:9:
../../go/pkg/mod/github.com/go-gl/glfw/v3.3/[email protected]/glfw/src/wl_window.c: In function ‘createTmpfileCloexec’:
../../go/pkg/mod/github.com/go-gl/glfw/v3.3/[email protected]/glfw/src/wl_window.c:53:10: error: implicit declaration of function ‘mkostemp’; did you mean ‘mkstemp’? [-Wimplicit-function-declaration]
   53 |     fd = mkostemp(tmpname, O_CLOEXEC);
      |          ^~~~~~~~
      |          mkstemp
../../go/pkg/mod/github.com/go-gl/glfw/v3.3/[email protected]/glfw/src/wl_window.c: In function ‘waitForData’:
../../go/pkg/mod/github.com/go-gl/glfw/v3.3/[email protected]/glfw/src/wl_window.c:204:32: error: implicit declaration of function ‘ppoll’; did you mean ‘poll’? [-Wimplicit-function-declaration]
  204 |             const int result = ppoll(fds, count, &ts, NULL);
      |                                ^~~~~
      |                                poll
../../go/pkg/mod/github.com/go-gl/glfw/v3.3/[email protected]/glfw/src/wl_window.c: In function ‘readDataOfferAsString’:
../../go/pkg/mod/github.com/go-gl/glfw/v3.3/[email protected]/glfw/src/wl_window.c:953:9: error: implicit declaration of function ‘pipe2’; did you mean ‘pipe’? [-Wimplicit-function-declaration]
  953 |     if (pipe2(fds, O_CLOEXEC) == -1)
      |         ^~~~~
      |         pipe

[dweymouth]

Hmm, this seems to be a GLFW (or at least a go-glfw) bug, this might need to be reported there. Also note that Wayland builds of Supersonic are still considered experimental and the supported way is still to run the X11 build through XWayland

[spezifisch]

Seems to be related to fyne-io/fyne#3517 (comment)
where they say it's not a problem. So I guess it's "wontfix" for us.
Also I suspect I had a dirty old working directory when getting error in the OP.

[Jacalz]

That compile error should not be happening with the latest go-gl/glfw code. It was fixed by go-gl/glfw#399 and is not related to fyne-io/fyne#3517 (one is a build error and the other one is a at runtime). I know that I updated Fyne to use this new version. Is Supersonic using the latest Fyne release?

[dweymouth]

Yes, based on release/v2.5.x

[Jacalz]

Wayland compiles work fine on release/v2.5.x and Fedora 40 (one of the Linux distros that is affected by the issue) for me and I get the expected output:

# github.com/go-gl/glfw/v3.3/glfw
In file included from ../../../../go/pkg/mod/github.com/go-gl/glfw/v3.3/[email protected]/c_glfw_lin.go:10:
../../../../go/pkg/mod/github.com/go-gl/glfw/v3.3/[email protected]/glfw/src/wl_window.c:29:9: warning: "_GNU_SOURCE" redefined
   29 | #define _GNU_SOURCE
      |         ^~~~~~~~~~~
<command-line>: note: this is the location of the previous definition

@spezifisch Are you sure that you really are building the latest version of Supersonic? I have confirmed that it does contain the fix and should not get those errors.

[Jacalz]

Wayland build fails with current state of main and develop.

This confuses me a bit. There does not seem to be any develop branch for supersonic?

[dweymouth]

Wayland build fails with current state of main and develop.

This confuses me a bit. There does not seem to be any develop branch for supersonic?

Yes indeed, Supersonic doesn't currently use a develop branch. Development happens in feature-specific branches with complete features and bug fixes merged directly to main. Not sure what spezifisch was referring to with develop

[spezifisch]

Wayland build fails with current state of main and develop.

This confuses me a bit. There does not seem to be any develop branch for supersonic?

Sorry for the confusion, I was mistaking it with one of the feature branches and I can't reproduce this error anymore. I think my initial report was based on an unclean state so we might as well close this.