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
