[MacPorts] #64270: lima: Build failure on old OS that uses legacysupport

[MacPorts]

#64270: lima: Build failure on old OS that uses legacysupport
-------------------------+--------------------
  Reporter:  ryandesign  |      Owner:  (none)
      Type:  defect      |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.7.1
Resolution:              |   Keywords:
      Port:  lima        |
-------------------------+--------------------

Comment (by ryandesign):

 > those binaries are needed by `lima`

 Ok, good to know.

 > Perhaps [...] restrict `lima` from building on macOS versions that are
 too old

 You could do this if you must, but if building Linux executables on macOS
 is something that other go ports might also need to do for similar
 reasons, then maybe we should take a moment to figure out why it doesn't
 work here and how to fix it.

 MacPorts and the legacysupport portgroup are providing a number of ldflags
 to the port which are only appropriate when building macOS software, yet
 it seems like the build is using them to try to build Linux software,
 which unsurprisingly does not work.

 The way that this appears to be happening is that the compiler_wrapper 1.0
 portgroup is being used (the lima portfile includes the golang 1.0
 portgroup which includes the legacysupport 1.1 and compiler_wrapper 1.0
 portgroups, so this issue potentially affects all go ports) and the
 compiler_wrapper portgroup creates compiler wrappers and tells the port to
 use them instead of using the compiler directly. The compiler wrappers
 contain some additional flags.

 On High Sierra, where legacy support is not in effect, the cc compiler
 wrapper contains:

 {{{
 #!/bin/bash
 export CCACHE_DIR=/opt/local/var/macports/build/.ccache
 exec /opt/local/bin/ccache /usr/bin/clang   -Os
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -pipe
 ${MACPORTS_LEGACY_SUPPORT_CPPFLAGS} "${@}"
 }}}

 so we see some cflags have been inserted. But on Sierra, where legacy
 support is in effect, it contains:

 {{{
 #!/bin/bash
 export CCACHE_DIR=/opt/local/var/macports/build/.ccache
 exec /opt/local/bin/ccache /usr/bin/clang   -Os
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.12.sdk -pipe
 ${MACPORTS_LEGACY_SUPPORT_CPPFLAGS} -Wl,-headerpad_max_install_names
 -L/opt/local/lib -lMacportsLegacySupport "${@//-static/}" -Wno-error
 }}}

 so we see that not only cflags but also ldflags have been inserted, which
 seems like it might be the source of the problem.

 Compiler wrappers can be troublesome since there may well be situations
 like the one lima is in now where it wants to compile some things without
 all of the flags added in the wrapper. MacPorts resisted the use of
 compiler wrappers for nearly two decades before this portgroup was created
 and managed to get by without them by instead supplying the correct flags
 in environment variables and ensuring that each port's build system obeys
 those environment variables (or other similar methods). Is there a way to
 make the golang portgroup and all go ports build this way, or at least the
 lima port?

 Alternately, is there a way that the compiler wrappers could be enhanced
 to avoid this problem? I don't know the complete set of arguments or
 environment variables that go is sending to the compiler wrapper, but for
 example if the `GOOS` environment variable gets passed through, then the
 compiler wrapper could choose to only add the legacysupport ldflags when
 `GOOS` is "darwin" (or is unset).

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