Changes between Initial Version and Version 1 of Ticket #57821, comment 7


Ignore:
Timestamp:
Dec 28, 2018, 8:54:30 PM (6 years ago)
Author:
mouse07410 (Mouse)
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #57821, comment 7

    initial v1  
    22
    33The problem is that I'm using **binaries** of other tools, therefore the decision what iconv library to use has been made by somebody else.
     4
     5> 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
    46
    57If 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.
     
    810> you'll have to build your program that uses that static library with macOS iconv...
    911
    10 I'll investigate this path...
     12I 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.
     13
     14I'll investigate the path you're suggesting.
    1115
    1216> Another thought is that you probably wouldn't run into the problem if you were using the MacPorts haskell port, ghc...