[MacPorts] #58935: go @1.13: build fails on 10.9 and less

MacPorts noreply at macports.org
Tue Oct 8 01:15:21 UTC 2019


#58935: go @1.13: build fails on 10.9 and less
---------------------+-------------------------------
  Reporter:  kencu   |      Owner:  ci42
      Type:  defect  |     Status:  assigned
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:  lion mountainlion
      Port:  go      |
---------------------+-------------------------------

Comment (by Ionic):

 I've implemented a proof-of-concept in https://github.com/macports
 /macports-legacy-support/compare/master...Ionic:bugfix/fdopendir-
 variations

 The only "proof" I was able to come up with so far is that my original
 plan doesn't work out:

 {{{
 :info:build Undefined symbols for architecture x86_64:
 :info:build   "_close$UNIX2003", referenced from:
 :info:build       _fdopendir$INODE64$UNIX2003 in fdopendir.dl.o
 :info:build   "_open$UNIX2003", referenced from:
 :info:build       _fdopendir$INODE64$UNIX2003 in fdopendir.dl.o
 :info:build   "_opendir$INODE64$UNIX2003", referenced from:
 :info:build       _fdopendir$INODE64$UNIX2003 in fdopendir.dl.o
 }}}

 This outcome makes sense. the `x86_64` architecture does not have any
 functions with the `$UNIX2003` tag. If I understand all of that correctly,
 the `x86_64` architecture was directly UNIX-certified and thus doesn't
 have any `$UNIX2003` functions. The `i386` architecture on the other hand
 wasn't certified and hence needs compatibility symbols that implement the
 functionality as mandated by SUS, since the "default implementation" is an
 Apple-specific, non-SUS-compliant one.

 The good part is that I can just filter out variants for architectures
 that don't support them.

 Doing that next.

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


More information about the macports-tickets mailing list