[MacPorts] #58138: go @1.12 fails to build on mavericks

[MacPorts]

#58138: go @1.12 fails to build on mavericks
---------------------+----------------------
  Reporter:  tehcog  |      Owner:  ci42
      Type:  defect  |     Status:  assigned
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:  2.5.4
Resolution:          |   Keywords:
      Port:  go      |
---------------------+----------------------

Comment (by Ionic):

 To make matters even more complicated,
 [https://github.com/golang/go/issues/17490 go recently (1.12) starting
 importing and using libSystem.dylib instead of using syscalls on OS
 X/macOS]. That COULD mean that additional libraries are not searched for
 when looking for symbols, but that needn't be.

 Regarding `fstat64`: [https://github.com/golang/go/issues/28984 they
 already had their share of problems with that one] and
 [https://github.com/golang/go/commit/e985ba80233ea5d222548f0a85370e98aaf8fa5d
 had to turn it off on iOS], because Apple regards the `64`-postfixed
 variants as either deprecated (for older syscalls) or completely private
 A[BP]I (for newer ones like `fstatat`) - and private A[BP]I might not be
 used in applications submitted to the App Store. Manual pages for OS
 X/macOS seem to indicate that this is true there as well, so the
 `64`-postfixed variants should be removed in `go`s darwin support
 infrastructure as well, but that's a bug for upstream, not us. What's
 more, recent iOS versions seem to set `_DARWIN_FEATURE_ONLY_64_BIT_INODE`
 and make the `64`-postfixed syscall versions accessible as the default.
 I'd have to check how that is on OS X/macOS, but chances are


 Generally, though, it feels like libMPLegacySupport should add support for
 the `64`-postfixed variants, even if only as aliases for the already
 implemented functions.

-- 
Ticket URL: <https://trac.macports.org/ticket/58138#comment:7>
MacPorts <https://www.macports.org/>
Ports system for macOS