Missing macOS libiconv.dylib Breaks ghc Bootstrap

[Ken Cunningham]

Steve, some thoughts, as I helped you fix issue this last time.

> Also, I’m perplexed with this doesn’t just work with the default MacPorts compiler.cpath and compiler.library_path settings. 

It seems this prebuilt bootstrap library you are using:

> /opt/local/var/macports/build/_opt_local_ports_lang_ghc/ghc/work/bootstrap/opt/local//lib/ghc-9.4.2/lib/x86_64-osx-ghc-9.4.2/base-4.17.0.0/libHSbase-4.17.0.0.a

Has been prebuilt against the system iconv with the system symbol names, and as it is prebuilt, you can’t change it. So you are forced to link against the system libiconv, as MacPorts libiconv will not be able to provide the needed symbols. 

The simplest way to accomplish that is to either clear LIBRARY_PATH like we did before to fix this, or set LIBRARY_PATH=/usr/lib, but I guess that either doesn’t work with hadrian or doesn’t do what you need it to do for some other reason.


Another way to force a specific libiconv.dylib is to specify the full pathname to the libiconv library you need to use, rather than use -liconv, like this:

LIBRARY_PATH='/opt/local/lib' clang -o hello -Wl,/usr/lib/libiconv.dylib hello.c

% otool -L hello
hello:
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)



NB. just don’t leave the old -liconv dangling as well, or you get this mess, which you surely don’t want:

LIBRARY_PATH='/opt/local/lib' clang -o hello -Wl,/usr/lib/libiconv.dylib -liconv  hello.c
% otool -L hello
hello:
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)



Note, it can be fragile to force /usr/lib/libiconv.dylib, as if there is anything else from MacPorts building and linking against libiconv with that link line, it will now try to link against the system libiconv version rather than the MacPorts version, and it will error out due to incorrect names, but in the opposite way.  

So — have to see what happens in that case, but there are ways that might be worked around too, by forcing -I to pick up the system iconv.h first.

Ken