[MacPorts] #43698: In libiconv, renaming of symbols from _iconv to _libiconv. Why?

[MacPorts]

#43698: In libiconv, renaming of symbols from _iconv to _libiconv. Why?
-----------------------------+------------------------
  Reporter:  cath.gasnier@…  |      Owner:  ryandesign
      Type:  defect          |     Status:  closed
  Priority:  Normal          |  Milestone:
 Component:  ports           |    Version:  2.2.1
Resolution:  invalid         |   Keywords:
      Port:  libiconv        |
-----------------------------+------------------------

Comment (by mouse07410):

 > I don't know why the developers chose to do things the way they did

 I don't want to call that choice stupid, but you can guess how I feel
 about it.

 > everything should work fine, provided you use the iconv.h header that
 matches the libiconv.dylib library you're using

 The problem is - I'm using Macports **tools** (like gcc8), and other
 **tools** like Haskell Platform.Tools - tools like in **binaries**. Which
 saved me (so far!) from the huge work of rebuilding every tool myself from
 source, and maintaining all that stuff - but it also means that I have
 little to no control over how those binaries are built. And in many cases,
 I cannot even force *rebilding* of those tools (Haskell). So, a lot of
 Macports tools are built with Macports libiconv and require it to be the
 first in the search path to run, while other tools (Haskell) are built
 with Apple iconv and require that one to be the first. And, as Haskell
 Platform is a tool for **building** other software, it **and whatever I
 build with it*** needs to see the system version of iconv first. Your
 suggestion from the other ticket would work, except that it would make it
 impossible to use tools from Macports packages together with those I build
 on Haskell Platform...

 None of the options are impossible. After all, Macports is open source, so
 it is possible to hack it and force all the ports I use - less than 600 in
 total - to use Apple's iconv. Equally, Haskell Platform is open source, so
 it is possible to rebuild it by hand, forcing it to use Macports iconv.
 But neither of these is either practical or appealing.

 Perhaps there could be a configuration option or variant for Macports
 libiconv that does **not** mangle the names? So I don't have to rebuild
 large packages by hand to overcome the damage libiconv developers upstream
 did?

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