[MacPorts] #66857: alex 3.2.7.1 fails to build

[MacPorts]

#66857: alex 3.2.7.1 fails to build
----------------------+--------------------
  Reporter:  jsalort  |      Owner:  (none)
      Type:  defect   |     Status:  new
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:  2.8.1
Resolution:           |   Keywords:
      Port:  alex     |
----------------------+--------------------
Changes (by ryandesign):

 * cc: saagarjha, CodingMarkus (added)


Comment:

 Replying to [comment:7 saagarjha]:
 > Presumably this isn't really a fix for upcoming releases of macOS. What
 should we do for those?

 Are you referring to the situation of new OS versions being released and
 buildbot workers not being immediately set up for them, or some other
 issue with a specific new version of macOS?

 Replying to [comment:8 CodingMarkus]:
 > I now have the same problem with alex-3.3.0.0_0 on macOS 14.1 (Sonoma).
 >
 > fetch alex-3.3.0.0_0+haskell_cabal_use_prebuilt.darwin_23.arm64.tbz2 is
 not found

 That's correct. There are no "darwin_23.arm64" binaries for any port yet.
 I haven't set up that buildbot worker yet.

 > and building fails because the symbol _iconv is not found.
 >
 > What I don't quite understand is:
 >
 > 1. Why do you force ghc to build against the system libiconv in the
 first place? ("because of the way we have built ghc, against the system
 libiconv")

 Explanations have been offered which I am too stupid to understand.

 > 2. If libiconv is so static ("as libiconv is very static"), how can
 there be undefined symbols? If it really was that static, then any version
 of it would offer the same symbols. Apparently the current version of it
 misses a symbol that the system version has, which sounds anything but
 static to me.

 A system version of libiconv intentionally uses different symbol names
 from a non-system version of libiconv. This is how libiconv was designed
 to work. It was intended to avoid conflicts, but with the way that ghc
 apparently misuses libiconv, it instead causes conflicts. If you have
 concerns about this, please have a dialog with the developers of ghc and
 libiconv.

 > To me this can only be solved in two ways: MacPorts always uses the
 system library and MacPorts never uses it. Make up your mind and then go
 with it. Any other concept was totally flawed to begin with and relying on
 a buildbot is no solution at all, it's a bloody workaround in lack of a
 real solution.

 MacPorts did decide, 20 years ago
 [changeset:aee9d56e39936c59de14c3ad363fbe28f7dc484d/macports-ports when
 libiconv was added to MacPorts], that ports would use a MacPorts version
 of libiconv. Same goes for most other libraries, even those already
 provided by the OS. Those decisions are not set in stone, of course, and
 could be changed if there were a good reason to, but I don't think there
 is. My uninformed view is that ghc is badly designed and why should
 MacPorts be changed to accommodate badly-designed software? I suggest
 finding a well-designed alternative to anything ghc-related.

 I agree that the buildbot is a nicety and designing ports that rely on its
 existence is a flawed strategy.

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