linking error between macOS and macport provided libiconv library #1208
The problem is widespread and long lasting with many long discussions.
_libiconv or _iconv undefined symbol on Mac OSX
R-Problems with iconv on macOS
Longstanding GHC linking issues when multiple iconv libraries are installed on macOS (Haskell #18743)
long discussion:
MacOS iconv linkage misdetection (also deprecation warnings) #830
libiconv breaks compatibility with OS-provided #57821
rav1e @0.6.6: iconv linking fails, expecting symbols from MacOS's iconv lib #68026
rav1e: build fails due to git_allocator missing members #68178
Examples of possible fixes:
ghc: Bugfixes for test and iconv linking #8523
Fix i/macOS libc++ initialization on early instrumentation #194
frida/frida-core
solution: libiconv on Mac OS X
FindIconv: Problem on macOS with mac ports
I can't imagine how cmake could possibly help you with this problem. The only thing cmake does is tell you where libiconv is located. It should not matter at all to your application whether it tells you about a system copy of libiconv like the one in /usr on macOS or a third-party copy of libiconv like the one in /opt/local provided by MacPorts, so long as you use both the headers and the library from the same place. The only way the problem you're experiencing could occur is if you're using the headers from one place and the library from another, so Don't Do That.
No comments:
Post a Comment