I have successfully self-bootstrapped ghc 9.4.2 by hand. I now believe that the build failures are caused by some default MacPorts setting.
Is someone able to suggest a Portfile setting that can recreate this successful build? I set (by hand) these basic MacPorts environment variables: > export CLANG=/usr/bin/clang > export CXX=/usr/bin/clang++ > export CPATH='/opt/local/include' > export LIBRARY_PATH='/opt/local/lib' > export LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names > -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -arch > x86_64' > export CPPFLAGS='-I/opt/local/include > -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk' > On Aug 28, 2022, at 7:34 PM, Steven Smith <steve.t.sm...@gmail.com> wrote: > > Also, I’m perplexed with this doesn’t just work with the default MacPorts > compiler.cpath and compiler.library_path settings. > > The file iconv.c has a straightforward #include <iconv.h> from > > https://github.com/ghc/ghc/blob/161a6f1fd62e797e978e7808a5f567fefa123f16/libraries/base/cbits/iconv.c#L4 > > <https://github.com/ghc/ghc/blob/161a6f1fd62e797e978e7808a5f567fefa123f16/libraries/base/cbits/iconv.c#L4> > > this should just use these: > >> CPATH='/opt/local/include' >> LIBRARY_PATH='/opt/local/lib' > > > > >> On Aug 28, 2022, at 3:01 PM, Steven Smith <steve.t.sm...@gmail.com >> <mailto:steve.t.sm...@gmail.com>> wrote: >> >> 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 >>> <mailto: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> >>>> <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
