Re: port-evbarm/51653: pkgsrc breaks on RPI - evbarm vs. earm

[christos%zoulas.com@localhost (Christos Zoulas)]

The following reply was made to PR pkg/51653; it has been noted by GNATS.

From: christos%zoulas.com@localhost (Christos Zoulas)
To: Benny Siegert <bsiegert%gmail.com@localhost>, gnats-bugs%NetBSD.org@localhost
Cc: pkg-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, pkgsrc-bugs%netbsd.org@localhost, 
	inbox@benjaminlorenz.email
Subject: Re: port-evbarm/51653: pkgsrc breaks on RPI - evbarm vs. earm
Date: Mon, 28 Nov 2016 13:56:12 -0500

 On Nov 28,  7:45pm, bsiegert%gmail.com@localhost (Benny Siegert) wrote:
 -- Subject: Re: port-evbarm/51653: pkgsrc breaks on RPI - evbarm vs. earm
 
 | > It does not (rely on compat). It should really be using the right values
 | > or they should be talking to us about making -1 or 0 meaning current, so
 | > they don't have to change it.
 | 
 | The point of contact for that would be me :) So what should Go put into its=
 |  binaries instead of what it is putting there? The thing is, if it needs a =
 | change on the NetBSD side, does that mean breaking compatibility with relea=
 | sed NetBSD versions?
 | 
 | The reason the 5.99.51 is in there is because this is what I was using at t=
 | he time for testing, and it was working. 5.x releases are clearly too old, =
 | anything from 6 on is fine.=20
 | 
 | It would be great if you could take a Go binary built on NetBSD 7 would als=
 | o run on NetBSD 6 though. That=E2=80=99s the way this works for the other O=
 | Ses, and it is a nice thing for deploying binaries.
 
 Binary compatibility on NetBSD is achieved in two different layers:
 
 1. kernel ABI 	keep old syscalls via compat_foo (static binaries mostly)
 2. lib ABI	wrap old lib calls to new syscalls (dynamic binaries mostly)
 
 Most binaries are dynamically linked and they use (2), go binaries
 are not and thus fall into (1). While the baked-into-binary ELF
 note version is not used much to determine what version of NetBSD,
 the binary was created on to make the kernel behave differently,
 it is used a little:
 
 https://nxr.netbsd.org/search?q=&project=src&defs=&refs=ep_osversion&path=&hist=
 
 The question is what is the right 'version' of NetBSD to put in the go binary?
 
 1. The running kernel version
 2. The cross-built userland environment version
 3. The go toolchain version (as determined by what NetBSD binary the
    toolchain was compiled on)
 4. Something I have not considered?
 
 I think 3 is probably the right choice, so the versioned backed into the
 go toolchain should be the value __NetBSD_Version__ at the time the go
 toolchain was built. It should be simple enough to get this value from
 <sys/param.h> and bake it into the the note that the go toolchain provides.
 
 Any opinions?
 
 christos