Thanks for the pointers. I now have this working with MacPorts libiconv.dylib libraries, and have bootrapped ghc and cabal binaries that are independent of /usr/lib/libiconv.dylib.
Relevant PR’s and issues: https://github.com/macports/macports-ports/pull/15770 <https://github.com/macports/macports-ports/pull/15770> https://gitlab.haskell.org/ghc/ghc/-/issues/22118 <https://gitlab.haskell.org/ghc/ghc/-/issues/22118> As far as I can tell this is a combination of issues with upstream breaking when the configure flag --with-system-libffi is set, along with the necessity of setting several C-appropriate flags during the build phase. Steve > On Aug 30, 2022, at 3:20 AM, Ken Cunningham <ken.cunningham.web...@gmail.com> > wrote: > > 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
smime.p7s
Description: S/MIME cryptographic signature
