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://github.com/macports/macports-ports/pull/15770>
https://gitlab.haskell.org/ghc/ghc/-/issues/22118 <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 <ken.cunningham.webuse at gmail.com> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220901/77852319/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/20220901/77852319/attachment.bin>