Re: Caddy webserver is not in the ports tree

On 2024-04-30, Souji Thenria <mail@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).