[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:7 mouse07410]:
 > > ... Which iconv library your tools use should have no bearing on what
 iconv library you want your own code to use ...
 >
 > The problem is that I'm using **binaries** of other tools, therefore the
 decision what iconv library to use has been made by somebody else.
 >
 > > 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
 >
 > If the problem was with what to use for **my build**, then indeed it
 would be trivial to resolve with a bit of {{{-L}}} and {{{-I}}} play.
 Unfortunately, there's nothing I can do - because iconv chose to force
 collision on the library name level and incompatibility on the library
 functions name level.

 I understand that you're using binaries. The decision of what iconv
 library **that binary** will use has already been made, that is correct.
 With the exception of the unique case of haskell's base static library, I
 don't see why that choice would affect you in any way.

 > > you'll have to build your program that uses that static library with
 macOS iconv...
 >
 > I think the main problem here is that the two libraries (MacOS and
 Macports) use the same lib name but different function names. The static
 vs. dynamic does not seem relevant - because of the function names
 mismatch the libHSbase cannot use libiconv interchangeably between MacOS
 and Macports, and if libHSbase were dynamic the situation would've been
 exactly the same.

 A dynamic library specifies by absolute path which libraries it uses, and
 so does a program.

 Consider the system CUPS library. It links with the system iconv library:

 {{{
 $ otool -L /usr/lib/libcups.2.dylib
 /usr/lib/libcups.2.dylib:
         /usr/lib/libcups.2.dylib (compatibility version 2.0.0, current
 version 2.12.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 1252.50.4)
         /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
 (compatibility version 5.0.0, current version 6.0.0)
         /System/Library/Frameworks/GSS.framework/Versions/A/GSS
 (compatibility version 1.0.0, current version 1.0.0)
 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
 (compatibility version 150.0.0, current version 1454.90.0)
 /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
 (compatibility version 1.0.0, current version 963.50.8)
         /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current
 version 1.0.0)
         /System/Library/Frameworks/Security.framework/Versions/A/Security
 (compatibility version 1.0.0, current version 58286.70.7)
         /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current
 version 7.0.0)
         /usr/lib/libz.1.dylib (compatibility version 1.0.0, current
 version 1.2.11)
 }}}

 Consider the MacPorts samba3 port's smbd program. It links with the system
 CUPS library and with the MacPorts iconv library:

 {{{
 $ otool -L /opt/local/sbin/smbd
 /opt/local/sbin/smbd:
         /opt/local/lib/libintl.8.dylib (compatibility version 10.0.0,
 current version 10.5.0)
         /usr/lib/libcups.2.dylib (compatibility version 2.0.0, current
 version 2.12.0)
         /usr/lib/libpam.2.dylib (compatibility version 3.0.0, current
 version 3.0.0)
         /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current
 version 1.0.0)
         /opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0,
 current version 9.0.0)
         /opt/local/lib/libpopt.0.dylib (compatibility version 1.0.0,
 current version 1.0.0)
         /opt/local/lib/samba3/libtalloc.dylib (compatibility version
 0.0.0, current version 0.0.0)
         /opt/local/lib/samba3/libtevent.dylib (compatibility version
 0.0.0, current version 0.0.0)
         /opt/local/lib/samba3/libtdb.dylib (compatibility version 0.0.0,
 current version 0.0.0)
         /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
 version 1.2.11)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 1252.50.4)
 }}}

 There is no problem. samba3 didn't need to know what iconv library the
 CUPS library uses. samba3 was free (at build time) to use either the
 system iconv library or the MacPorts iconv library, and it does not
 interfere with what CUPS used.

 On the other hand, if smbd tried to link with a static library of CUPS, it
 would very much matter, because a static library is essentially like
 copying all of the library's code into your program. If that static
 library links with other dynamic libraries, you must supply the flags to
 do so when you use the static library, just as if you had used that other
 dynamic library directly in your own code. And because in your case the
 haskell static library was compiled for the system iconv, you must also
 use the system iconv.

 > I'm already using a non-Macports copy of GHC - which is what brought all
 this issue up in the first place. How can I help you guys update yours?

 If interested, discuss it in #48899 or contact the maintainer.

 > **Is it possible to create a {{{libiconv}}} variant that does not mangle
 function names? Would you consider that?**

 Yes, it is possible, but no, I will not add that to the port, because it
 will cause problems—much like the ones you're experiencing now, just in
 different circumstances—which I do not wish to spend time helping users
 resolve.

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