On 2024/07/07 21:09, Kian Ali Agheli wrote: > > OpenBSD recently changed access to its syscalls. > The change which allows upstream Go to build working executables > for current OpenBSD was committed on May 4th. > https://github.com/golang/go/commit/8841f50d98b224ecf5ee27d9b7e6f18ad2c98e46
That is not in a go release yet. Should be in 1.23 when ready. It is however in the OpenBSD ports version of go 1.22.4 (and earlier). It's a bodge and is there mainly because go's standard libraries don't provide OS-related functions that people have been wanting. This code in go only handles ioctl/sysctl syscalls however some go software does all sorts of things using syscalls - they don't want to depend on libc so they depend on low level kernel interfaces instead. (the equivalent bodge that we have in perl, see syscall_emulator.c etc, supports a much wider range). > $ git clone https://github.com/kovidgoyal/kitty . > $ grep -r syscall * > ... > kittens/transfer/receive.go:func syscall_mode(i os.FileMode) (o uint32) { > kittens/transfer/receive.go: if err := > unix.Fchmodat(unix.AT_FDCWD, self.expanded_local_path, > syscall_mode(self.permissions), unix.AT_SYMLINK_NOFOLLOW); err == nil || > !(errors.Is(err, unix.EINTR) || errors.Is(err, unix.EAGAIN)) { > kittens/transfer/send.go: "syscall" > kittens/transfer/send.go: stat, ok := stat_result.Sys().(*syscall.Stat_t) > kittens/transfer/send.go: stat, ok := > st.Sys().(*syscall.Stat_t) > ... Those references in kittens seem to be using functions like os.Stat and unix.Fchmodat which IIRC should work ok as long as they're built against current versions of go libraries. The 'syscall' references in those files are I think due to using structs coming from the Go syscall library but not using syscall() themselves. There is some direct use of syscall in https://github.com/kovidgoyal/kitty/blob/2076cd870a3f0a56333151f9df2dcb1719aee61e/tools/utils/filelock.go#L16 but I don't know if that affects kittens. There's also https://github.com/kovidgoyal/kitty/blob/2076cd870a3f0a56333151f9df2dcb1719aee61e/tools/utils/shm/shm_syscall.go#L67 but that's not set to build on openbsd. I didn't check the libraries listed in kitty's go.mod so there might still be some uses hiding there. If someone wants to fix this I suggest starting by building "kitten" with the openbsd packages version of the go compiler and see if things still fail. It may work as-is,but if not, it's likely to then be a runtime error rather than outright refusal to run. If it's still broken, figure out which code is actually using syscall. If it's a library there may be a newer version or fork which doesn't do that. Or there might be a more portable alternative method that could be used instead. (btw, the version of kitty in ports is older, from when "kittens" were written in python. last time we tried updating, we had problems with the go components as it wanted to download during build, which is not allowed for ports - that might be fixable but I don't think anyone wanted to put that much effort in to cope with a terminal emulator - especially one which seems to take the diametrically opposite view to OpenBSD regarding complexity vs simplicity!)
