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
