On 2024-04-30, Souji Thenria <m...@souji-thenria.net> wrote: > > Could you elaborate on your point that Go ports are a pain? > I thought a port written in Go would probably be easier to maintain > because no additional libraries are needed to run the program, and > cross-compilation is relatively easy, too.
With current OpenBSD versions, system calls are only permitted from libc, so all binaries making any system calls need to be linked with libc. There's a common idiom in software written in Go to try to avoid touching anything in C libraries and issue system calls directly instead - this no longer works on OpenBSD (there is a special case because the Go compiler has been patched to reroute SYS_IOCTl and SYS_SYSCTL to the libc wrapper automatically but for any others, patches are required). Additionally software needs to use a recent enough version of golang.org/x/sys and not use an old version via vendoring or modules otherwise x/sys's own use of syscall is a problem. Cross-compilation of go software to run on current OpenBSD is mostly not possible at the moment because the compiler changes mentioned above are added via patches in the port and won't be in compiler binaries produced for other OS. There's another issue with the go module system used for "standard" modern go ports: it mostly wants unmodified .mod and .zip files so it's hard for a port to apply patches to anything other than the source code for the main piece of software (i.e. not dependent modules). There is a way around this in some cases by feeding in the zip/mod files in a first stage and using "go mod vendor" to extract them before build, allowing them to be patched, but this is a delicate and not very pleasant area to work on (it's easy to break existing ports, some of which already have bodges to work around this, also compiling all the current ports using go to test any such changes uses loads of disk space, cpu, and time).
