[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