Changes between Initial Version and Version 1 of Ticket #57821, comment 7
- Timestamp:
- Dec 28, 2018, 8:54:30 PM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #57821, comment 7
initial v1 2 2 3 3 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. 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 4 6 5 7 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. … … 8 10 > you'll have to build your program that uses that static library with macOS iconv... 9 11 10 I'll investigate this path... 12 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. 13 14 I'll investigate the path you're suggesting. 11 15 12 16 > Another thought is that you probably wouldn't run into the problem if you were using the MacPorts haskell port, ghc...