[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    |
-------------------------+------------------------

Comment (by mouse07410):

 > The developers of libiconv have decreed that a system copy of libiconv
 shall not mangle the function names, and any third-party copies of
 libiconv shall mangle the names. MacPorts is a third party, so its copy of
 libiconv does mangle the names

 And I find their decision to be extremely bad for the problems it is
 causing, as described here and in the other ticket #43698.

 > One solution, if you want to ... use the system iconv and not MacPorts
 libiconv, but ... other libraries like openssl from MacPorts

 Yes, thank you - this might work (and is a good advice). Except that I
 don't see how Macports-provided binaries could work together with, e.g.,
 Haskell and Haskell-built binaries. For example, Haskell invokes either
 gcc or clang - and Macports versions require Macports iconv.

 > The macports-users list is probably appropriate for this question

 Will try that, thanks.

 Another possibility probably is making a fake port of iconv that simply
 points at the system iconv, and forcing Macports to use that one. And
 force-rebuild less than 300 ports on one machine, and less than 600 ports
 on another. ;-)
 What do I need to do to create such a fake port?

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