[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