[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:3 mouse07410]:
 > > depending on the OS...
 >
 > But this is a **Macports** version of {{{libiconv}}} - therefore the
 only OS it should target (e.g., via Macports patches) should be MacOS,
 right?

 Yes, but that doesn't really matter. 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.

 > Also, the **name of the library** does collide - which makes it
 impossible to use packages that require, e.g., a modern (Macports-
 installed) OpenSSL that resides in {{{/opt/local/lib}}} and OS-provided
 libiconv that resides in {{{/usr/lib}}}. If I don't add
 {{{/opt/local/lib}}} - then **all** the older OS-provided libraries would
 be used, in which case what's the point of using Macports? And if I add
 {{{/opt/local/lib}}} before the default {{{/usr/lib}}} - then
 {{{/opt/local/lib/libiconv.dylib}}} gets used because it carries the same
 name as {{{/usr/lib/libiconv.dylib}}}.

 One solution, if you want to ensure that you use the system iconv and not
 MacPorts libiconv, but you still want to use other libraries like openssl
 from MacPorts, is to create a new directory anywhere, and inside that,
 create lib and include directories, and inside those, put symlinks to the
 system iconv files. Then add `-I` and `-L` flags to your build system
 pointing to those directories. Place those flags before the flags that
 point to the MacPorts directories.

 > If the developers were concerned about the conflict with an OS-provided
 iconv library - why on earth did they keep **exactly** the same name? To
 ensure the conflict would occur, by binary distributions linked with one
 library stumbling upon the other?
 >
 > Comrade Stalin used to say about such cases "Ни Богу свечка, ни чёрту
 кочерга".

 I cannot answer this; ask the developers. They probably are not reading
 this ticket and won't see your questions here.

 > >
 > > If you need help resolving it, you could ask on the MacPorts mailing
 lists
 >
 > Could you please point me at the appropriate mailing list? Thanks!

 Our lists are here:

 https://www.macports.org/contact.php#Lists

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

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