Re: go14 build failure

[Robert Swindells <rjs%fdy2.co.uk@localhost>]

Greg Troxel <gdt%lexort.com@localhost> wrote:
>Martin Husemann <martin%duskware.de@localhost> writes:
>
>> On Sun, Oct 01, 2017 at 08:19:32PM +0100, Patrick Welche wrote:
>>> Your guess is spot on! I was running a kernel with no compat at all.
>>> Tried adding
>>> 
>>> include         "conf/compat_netbsd70.config"
>>> 
>>> but that wasn't enough, so I went all the way to netbsd15.config, and
>>> then managed to compile go14.
>>
>> Benny, as you basically said netbsd-8 (or maybe a late version of -7)
>> would be required for proper golang anyway, would it make sense to
>> align the syscall renames and argument structures with -8 and then bump
>> the binary version magic too?
>
>I'm having trouble following.
>
>It seems there was a kernel bug triggered by recent go, and that's been
>fixed in current, and -8, and perhaps -7.  (It would be nice to have -6
>be ok, because it's supported until -8 comes out, but I can understand
>reduce motivation for that.)

Correct, it isn't really related to this though.

>Is the need for compat in the kernel because people are using a
>go14 built on 7 on 8?  If so, that's fine.   If a package built on a
>particular version needs compat code to run on that same version, that
>doesn't seem right.  Is something in go intentionally using old
>syscalls?

It is a bug in go14. This is the final version of Go that was written
in C rather than in itself so it is used to bootstrap later versions.

The Go runtime calls syscalls directly so it doesn't pick up the
symbol versioning trick from the system C headers, instead the source
explicitly references the renamed syscalls, at least one of these
has been missed so that the runtime is still using the original syscall.

Somebody needs to ktrace a build of go14 and find the offending syscall.

The same bug may or may not exist in later versions of Go, we haven't
checked yet.

Robert Swindells