[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: go14 build failure
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
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
Main Index |
Thread Index |