[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 ryandesign):

 Replying to [comment:5 mouse07410]:
 > > 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 library search paths specified with `-L` and the header search paths
 specified with `-I` are only relevant at build time. After a tool like
 gcc8 has been built with those flags, those flags are no longer relevant
 for it. gcc8 will happily use whichever iconv library it was built to use,
 because it's linked with it by its absolute path—no search paths are
 involved. Which iconv library your tools use should have no bearing on
 what iconv library you want your own code to use; you can determine that
 by using the right `-L` and `-I` flags at the time that you compile your
 code.

 But I see above that the problem is occurring in a haskell static library
 libHSbase-4.11.1.0.a. That is indeed a bit of a special case. The use of
 static libraries is discouraged on macOS, perhaps partly because it can
 cause problems like this. If you were using a dynamic version of libHSbase
 (and if they provide one, maybe you can try that) there should be no
 problem, because as I said above the absolute path to the correct iconv
 library to use will be baked into the dynamic library. And it's no problem
 if you want to use a different iconv than that in your own code; it's the
 libiconv name mangling that makes that possible.

 If you continue to use the static library, then because the static library
 was built with macOS iconv you'll have to build your program that uses
 that static library with macOS iconv as well by supplying `-L` and `-I`
 flags that put the macOS iconv library first, as I suggested above with
 the temporary directories and symlinks.

 Another thought is that you probably wouldn't run into the problem if you
 were using the MacPorts haskell port, ghc. However, as you know, it's
 [ticket:48899 out of date], and if you need features of ghc 8, then you'll
 have to use a non-MacPorts copy (or help us update ours).

 > 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?

 I don't think there is any reason why you should need to do that, so I
 don't want to provide advice for doing that, and I don't want to then
 provide further support to solve the problems that doing that will create.

 If you need further help compiling your own program using MacPorts
 libraries, do ask on the macports-users mailing list. But I think we
 should stop discussing it in this ticket, because our issue tracker is for
 bug reports—problem we can fix by committing a change to MacPorts. In this
 case, libiconv is working as designed, so there is nothing for us to
 change. If you disagree with the design, you have to talk to the
 developers of libiconv about it, but libiconv has worked this way for a
 long time, so it is probably unlikely that they will change the design at
 this point.

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