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

MacPorts noreply at macports.org
Sun Jan 6 18:53:26 UTC 2019


#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):

 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.

 All of these problems would not exist if Macports could provide a variant
 of {{{libiconv.dylib}}} **with no mangled names**.

 Based on the above, I have to ask @ryandesign again to reconsider. All the
 other venues I've explored so far, don't seem to cover the desired set of
 use cases.

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


More information about the macports-tickets mailing list