Re: Missing macOS libiconv.dylib Breaks ghc Bootstrap

[Steven Smith]

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://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  
> 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

Re: Missing macOS libiconv.dylib Breaks ghc Bootstrap

[Steven Smith]

I see that my build environment does not include some of these variables (CC, 
CFLAGS, LDFLAGS, etc.). It sets:

> :debug:build Environment:
> :debug:build CC_PRINT_OPTIONS='YES'
> :debug:build 
> CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_ports_lang_ghc/ghc/work/.CC_PRINT_OPTIONS'
> :debug:build CPATH='/opt/local/include'
> :debug:build DEVELOPER_DIR='/Library/Developer/CommandLineTools'
> :debug:build LIBRARY_PATH='/opt/local/lib'
> :debug:build MACOSX_DEPLOYMENT_TARGET='12.0'
> :debug:build MACPORTS_LEGACY_SUPPORT_DISABLED='1'
> :debug:build SDKROOT='/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk'

This may be the cause of the build failure. How do I set the build environment 
variables CC, CFLAGS, etc.?

I’ve added this command to the Portfile, but it doesn’t change the build 
environment,

> build.env-append \
> "CC=${configure.cc}" \
> "CFLAGS=${configure.cflags}" \
> "CPATH=${compiler.cpath}" \
> "CPPFLAGS=${configure.cppflags}" \
> "CXX=${configure.cxx}" \
> "CXXFLAGS=${configure.cxxflags}" \
> "LDFLAGS=${configure.ldflags}"





> On Aug 30, 2022, at 9:05 PM, Steven Smith  wrote:
> 
> 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 > > 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  from 
>> 
>> 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 >> > 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
  T _hs_iconv_open
  U _iconv_open
  U _hs_iconv_open
 3e02 T _libiconv_open
 5375 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 >>> > wrote:
 
 On 2022-8-29 04:42 , Steven Smith wrote:
> Re: 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 

Re: 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  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  from 
> 
> 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 > > 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
>>>  T _hs_iconv_open
>>>  U _iconv_open
>>>  U _hs_iconv_open
>>> 3e02 T _libiconv_open
>>> 5375 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 >> > wrote:
>>> 
>>> On 2022-8-29 04:42 , Steven Smith wrote:
 Re: 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

Re: Missing macOS libiconv.dylib Breaks ghc Bootstrap

[Ken Cunningham]

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

Re: Missing macOS libiconv.dylib Breaks ghc Bootstrap

[Steven Smith]

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  from 

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  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
>>  T _hs_iconv_open
>>  U _iconv_open
>>  U _hs_iconv_open
>> 3e02 T _libiconv_open
>> 5375 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 > > wrote:
>> 
>> On 2022-8-29 04:42 , Steven Smith wrote:
>>> Re: 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

Re: Missing macOS libiconv.dylib Breaks ghc Bootstrap

[Joshua Root]

On 2022-8-29 05:01 , Steven Smith 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

 T _hs_iconv_open
                 U _iconv_open
                 U _hs_iconv_open
3e02 T _libiconv_open
5375 T _libiconv_open_into


Is there a way to hack this out to transform _iconv_open to 
_libiconv_open in the .a file?


If you use the correct header that goes with the library, it will be 
transformed in the source via macros. If the place these references come 
from isn't using C headers, I guess they have to be edited some other 
way. (You could also theoretically make a shim lib, but that's getting a 
bit overcomplicated for the problem at hand…)


- Josh

Re: Missing macOS libiconv.dylib Breaks ghc Bootstrap

[Steven Smith]

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
>  T _hs_iconv_open
>  U _iconv_open
>  U _hs_iconv_open
> 3e02 T _libiconv_open
> 5375 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  wrote:
> 
> On 2022-8-29 04:42 , Steven Smith wrote:
>> Re: 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

Re: Missing macOS libiconv.dylib Breaks ghc Bootstrap

[Joshua Root]

On 2022-8-29 04:42 , Steven Smith wrote:
Re: 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

Re: Missing macOS libiconv.dylib Breaks ghc Bootstrap

[Steven Smith]

P.S. CLT provides the file

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libiconv.tbd

But is points to the nonexistent file:

> install-name:'/usr/lib/libiconv.2.dylib'



> On Aug 28, 2022, at 2:42 PM, Steven Smith  wrote:
> 
> Re: 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?
> 



smime.p7s
Description: S/MIME cryptographic signature

Missing macOS libiconv.dylib Breaks ghc Bootstrap

[Steven Smith]

Re: 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?



smime.p7s
Description: S/MIME cryptographic signature