Thanks. > you probably want to be using the libiconv port anyway?
Unfortunately, that won’t work without some hackery. Note the different symbol names in MacPorts: > nm -gC > /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 > /opt/local/lib/libiconv.dylib | grep iconv_open > 0000000000000000 T _hs_iconv_open > U _iconv_open > U _hs_iconv_open > 0000000000003e02 T _libiconv_open > 0000000000005375 T _libiconv_open_into Is there a way to hack this out to transform _iconv_open to _libiconv_open in the .a file? > On Aug 28, 2022, at 2:57 PM, Joshua Root <j...@macports.org> wrote: > > On 2022-8-29 04:42 , Steven Smith wrote: >> Re: https://gitlab.haskell.org/ghc/ghc/-/issues/22118 >> <https://gitlab.haskell.org/ghc/ghc/-/issues/22118> >> I'm self-bootstrapping ghc 9.4.2 using hadrian for deployment on MacPorts. >> Running hadrian -f binary-dist throws this error: >>> :info:build "_iconv_close", referenced from: >>> :info:build _hs_iconv_close in libHSbase-4.17.0.0.a(iconv.o) >>> :info:build (maybe you meant: _hs_iconv_close) >>> :info:build "_iconv", referenced from: >>> :info:build _hs_iconv in libHSbase-4.17.0.0.a(iconv.o) >> The archive file libHSbase-4.17.0.0.a in the ghc install uses the undefined >> symbol _iconv_close; however, macOS 12.5.1 no longer appears to provide a >> system libiconv: >>> ls /usr/lib/libiconv* >>> ls: /usr/lib/libiconv*: No such file or directory >> And port iconv provides the _libiconv_open symbol, not the _iconv_open >> symbol. >> Is anyone aware of a solution to a missing libconv.dylib on recent macOS? > > It's not actually missing, it just doesn't exist as a file in the filesystem. > All OS-supplied libraries now exist only in the shared dyld cache. (The SDK, > as you discovered, contains text-based stubs with just enough information > about exported symbols and whatnot to allow linking.) > > That does mean that all build systems that check for the existence of a > .dylib file to see if a library is available are broken. If checking is > really necessary, they need to check if they can link with the library > instead. > > For deployment in MacPorts though, you probably want to be using the libiconv > port anyway? > > - Josh
smime.p7s
Description: S/MIME cryptographic signature
