Missing macOS libiconv.dylib Breaks ghc Bootstrap

[Steven Smith]

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.smith at 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.smith at gmail.com <mailto:steve.t.smith at 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 <jmr at macports.org <mailto:jmr at 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
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220830/3266b7b4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3898 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220830/3266b7b4/attachment.bin>