[MacPorts] #57821: libiconv breaks compatibility with OS-provided

[MacPorts]

#57821: libiconv breaks compatibility with OS-provided
-------------------------+------------------------
  Reporter:  mouse07410  |      Owner:  ryandesign
      Type:  defect      |     Status:  closed
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:  invalid     |   Keywords:
      Port:  libiconv    |
-------------------------+------------------------
Changes (by ryandesign):

 * status:  reopened => closed
 * resolution:   => invalid


Comment:

 Replying to [comment:15 mouse07410]:
 > Here's the latest update, after a long discussion with the GHC
 developers.
 >
 > - Passing {{{-L/dir/for/libiconv}}} to GHC for some reason does not work
 as expected. Theoretically it should, in practice it doesn't.
 > - Making {{{libHSbase.a}}} dynamic-only would remove the ability to
 distribute pre-packaged binaries, because then they would run only on
 systems where GHC is installed. Therefore, it's been decided by the GHC
 developers that it's not an acceptable option.
 > - Building a Macports-aware GHC works, but prevents distributing
 binaries to systems that don't have Macports installed.

 Neither offering a dynamic version of the HSbase library, nor using a
 MacPorts ghc, would prevent you from distributing binaries built with it.
 You can relocate any needed dynamic libraries into your application
 bundle, either manually by running `install_name_tool` as needed or by
 automating it using a tool such as `dylibbundler` (which can be installed
 with MacPorts).


 Replying to [comment:16 mouse07410]:
 > Re-opening with the request to re-consider adding a variant to
 {{{libiconv.dylib}}}

 I'm not going to do that; I've explained why. Now please, let us stop
 talking about this issue. I don't want to spend any more time on it.

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