x/sys/unix: __sysctl is used on iOS instead of sysctl

[zx2c4]

In issue #34133, @mmaxim reported that the app store was rejecting his app due to the use of __sysctl, which he ascribed to the Go runtime. However, it turns out that the Go runtime uses sysctl, whereas it was x/sys/unix using __sysctl. So, x/sys/unix should be adjusted to use sysctl instead of __sysctl.

CC @eliasnaur

[gopherbot]

Change https://golang.org/cl/202778 mentions this issue: syscall: reenable sysctl on iOS

[gopherbot]

Change https://golang.org/cl/202837 mentions this issue: unix: __sysctl is sysctl on darwin

[eliasnaur]

Thank you. I'm sorry that I wasn't more thorough. Is this a backport candidate?

[zx2c4]

Thank you. I'm sorry that I wasn't more thorough. Is this a backport candidate?

x/sys/unix is not relevant for backports. Perhaps you meant to chime in on #35101 for which there is already a backport candidate in #35105

Or are you thinking that we should update the vendored x/sys/unix and backport that?

[gopherbot]

Change https://golang.org/cl/202779 mentions this issue: [release-branch.go1.13] syscall: reenable sysctl on iOS

[alexaliu]

The change fails for me on macOS 10.14.6 (mojave) with

vendor/golang.org/x/sys/unix.libc_sysctl_trampoline·f: relocation target vendor/golang.org/x/sys/unix.libc_sysctl_trampoline not defined

I think the issue is that the assembly files still refer to
libc___sysctl_trampoline and libc___sysctl instead of libc_sysctl. Changing it to lib_sysctl fixes the issue for me, at least for amd64.

These files look like they're generated though, so I'm not sure if this analysis is correct.

[gopherbot]

Change https://golang.org/cl/202958 mentions this issue: unix: regenerate darwin libc trampolines after CL 202837