Skip to content

Longstanding GHC linking issues when multiple iconv libraries are installed on macOS

Motivation

There is an old, well-known, and annoying problem with ghc on macOS when there are multiple iconv libraries installed. This isn't necessarily an issue with ghc itself, but the problem is encountered so frequently and wastes so much time I hope that the ghc community could offer a fix or advice to address it, whether in ghc itself or the build process, beyond the basic workaround of uninstalling the extra libiconv.

I've looked for and haven't been able to identify the actual fix, which preferably would be to make the build completely dependent on native /usr/lib/libiconv.dylib, or the extra installed libiconv.

The basic problem looks like this (e.g. on this MacPorts test of ghc):

:info:test Linking mk/ghc-config ...
:info:test Undefined symbols for architecture x86_64:
:info:test   "_iconv", referenced from:
:info:test       _hs_iconv in libHSbase-4.14.0.0.a(iconv.o)

In ghc's Portfile, all the obvious things I and others have tried appear not to work, e.g. specifying LIBRARY_PATH so that the build finds /opt/local/lib/libiconv.dylib.

How should ghc be built to either rely entirely on the native /usr/lib/libiconv.dylib or a user-installed libiconv so that this recurring issue can be avoided?

See also

Edited by Ben Gamari
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information