<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thanks for the pointers.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Relevant PR’s and issues:</div><div class=""><ul class="MailOutline"><li class=""><a href="https://github.com/macports/macports-ports/pull/15770" class="">https://github.com/macports/macports-ports/pull/15770</a></li><li class=""><a href="https://gitlab.haskell.org/ghc/ghc/-/issues/22118" class="">https://gitlab.haskell.org/ghc/ghc/-/issues/22118</a></li></ul><div class=""><br class=""></div></div><div class="">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.</div><div class=""><br class=""></div><div class="">Steve</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 30, 2022, at 3:20 AM, Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" class="">ken.cunningham.webuse@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Steve, some thoughts, as I helped you fix issue this last time.<br class=""><br class=""><blockquote type="cite" class="">Also, I’m perplexed with this doesn’t just work with the default MacPorts compiler.cpath and compiler.library_path settings. <br class=""></blockquote><br class="">It seems this prebuilt bootstrap library you are using:<br class=""><br class=""><blockquote type="cite" class="">/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<br class=""></blockquote><br class="">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. <br class=""><br class="">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.<br class=""><br class=""><br class="">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:<br class=""><br class="">LIBRARY_PATH='/opt/local/lib' clang -o hello -Wl,/usr/lib/libiconv.dylib hello.c<br class=""><br class="">% otool -L hello<br class="">hello:<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)<br class=""><br class=""><br class=""><br class="">NB. just don’t leave the old -liconv dangling as well, or you get this mess, which you surely don’t want:<br class=""><br class="">LIBRARY_PATH='/opt/local/lib' clang -o hello -Wl,/usr/lib/libiconv.dylib -liconv hello.c<br class="">% otool -L hello<br class="">hello:<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)<br class=""><br class=""><br class=""><br class="">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. <br class=""><br class="">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.<br class=""><br class="">Ken</div></div></blockquote></div><br class=""></div></body></html>