On Tue Apr 30, 2024 at 5:09 PM BST, Stuart Henderson wrote:
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.
Interesting; I was not aware that OpenBSD only allows system calls from
libc. As you mentioned, I always thought that trying to avoid C
libraries in Go is the best way to avoid incompatibilities.
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).
I never would have thought the module system used by Go would be such a
hurdle. However, from the perspective of the need to change
dependencies, it makes sense that the module system is not optimal for
this task.
Thank you very much. This changes my perception of Go a lot (at least
regarding maintaining ports written in Go).
Regards,
Souji
