Go Ports: Update PG to Ensure Ports Aren't Built if Version Required Not Available

[Fred Wright]

On Thu, 27 Jul 2023, Ken Cunningham wrote:

> The last time I looked at this, go had moved on to use newer features of 
> the Security.Framework that couldn't be duplicated for older systems, so 
> it was stuck at an older pegged version.

The last time I looked at issues building go, motivated by llvm's 
propensity for attempting to opportunistically build a go binding and 
often falling on its face in the process, I noticed that the go build 
includes bindings for a lot of system calls in order to avoid the user's 
needing to create glue code for them.  But the list of calls for this is 
fixed, based on whatever OS version the go developers chose as a target. 
If any call in the list is unavailable, go fails to build, even if go 
itself doesn't need the call at all, and even if the user has no intention 
of running any go program that uses that call.  On the flip side, if one 
is using a newer OS than go's target, then one still needs to roll one's 
own glue code.

Clearly the right way to handle this is to make the list of calls with 
this treatment vary as a function of the OS being built for.  In the 
process, it might make sense to use legacy-support optionally, depending 
on whether the goal is to maximize standardness or to maximize capability.

Fred Wright