[MacPorts] #60477: stack @2.3.1_0: Undefined symbols: _utimensat

[MacPorts]

#60477: stack @2.3.1_0: Undefined symbols: _utimensat
-------------------------+-------------------------------------------------
  Reporter:  macdeport   |      Owner:  essandess
      Type:  defect      |     Status:  assigned
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.6.2
Resolution:              |   Keywords:  sierra elcapitan yosemite mavericks
      Port:  stack       |  mountainlion lion snowleopard leopard tiger
-------------------------+-------------------------------------------------

Comment (by kencu):

 Replying to [comment:21 Ionic]:
 > It's tricky and almost impossible because of some bugs.

 I actually don't see any bugs in this. Just the way it works.

 >
 > The general idea is to pass `--ghc-options
 "-optc-I${prefix}/include/LegacySupport
 -optl${prefix}/lib/libMacportsLegacySupport.dylib"` to the build process,
 which works surprisingly well.

 Yeah, that is the command-line equivalent to what I offered here
 [ticket:60477?replyto=21#comment:16] before.


 I moved my fix as per the yaml file into my main {{{config.yaml}}} on my
 older systems, so now legacy support is always used when building with
 stack. No more troubles ;>


 > Sadly, turning `${configure.cflags}` and `${configure.ldflags}` into ghc
 options (i.e., `-optc...` and `-optl...`) won't work, because this will
 also add `-optl-L${prefix}/lib` and `-optc-I${prefix}/include`, which will
 make packages within stack link against the GNU iconv implementation and
 fail to find the symbols later on. Not sure why, probably because Apple's
 iconv implementation is different, but that's definitely an issue to
 avoid, so we'll just the library and add the `legacy-support`-related
 include directory only manually.


 This {{{iconv vs libiconv}}} symbol-naming issue goes back many many
 years. {{{libiconv}}} does that on purpose -- different sympbols for
 system vs user installations of {{{libiconv}}} to find and flag misbuilt
 and/or misconfigured software that mixes up headers and libraries, which I
 guess they found was all too common (and apparently still is ;>  ).



 I have updated my builds of the haskell ecosystem for 10.6+, including
 ghc-9.x, stack 2.71, cabal 3.40, and the needed alex and happy versions.
 All this haskell stuff works great for me back to 10.6.8 still, and I can
 build anything I want, eg pandoc and shellcheck on Lion:

 {{{
 $ port -v installed pandoc
 The following ports are currently installed:
   pandoc @2.13_0 (active) requested_variants='' platform='darwin 11'
 archs='x86_64' date='2021-05-27T07:31:22-0700'
 }}}

 The {{{stack}}} that is downloaded from upstream is built on a system that
 is not friendly to older systems. I just replace that one in the port with
 my own, and everything is 100%.

 I may update the {{{stack}}} port here on MacPorts to use the one I have
 which actually works on older systems, but perhaps it would be easier to
 just make the binaries of pandoc and shellcheck available because in the
 end, that is pretty much all that people want this for anyway.

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