<div dir="ltr"><div>I'm trying to diagnose strange GHC linking behavior which, as far as I can tell, only occurs on macOS. I feel a bit out of my league debugging this, so I'm hoping someone knows what is causing this.<br></div><div><br></div><div>When building the Haskell libffi library [1], it will link pass -lffi to GHC. Typically, most installations of libffi will include both a static library (libffi.a) and a shared library (libffi.{so,dylib,dll}). My impression is that when the linker finds both, it will default to the shared library. This is definitely the case on Linux and Windows, at least.</div><div><br></div><div>An exception to this rule is macOS, however. On macOS, building libffi always appears to default to linking against the static version of libffi, even when a dynamic version is also available. To reproduce this phenomenon, check out libffi [1] and run the following commands:</div><div><br></div><div>    $ brew install libffi # If it is not already installed<br></div><div>    $ cabal build ctime<br></div><div>    $ otool -L $(cabal list-bin ctime)</div><div><br></div><div>The output reveals that the compiled executable does not dynamically link against libffi.dylib:</div><div><br></div><div>    $ otool -L $(cabal list-bin ctime)<br>    /Users/rscott/Documents/Hacking/Haskell/libffi/dist-newstyle/build/x86_64-osx/ghc-8.10.7/libffi-examples-0.1/x/ctime/build/ctime/ctime:<br>            /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)<br>            /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)<br>            /usr/lib/libcharset.1.dylib (compatibility version 2.0.0, current version 2.0.0)</div><div><br></div><div>This is exceedingly strange, since my Hombrew installation does in fact provide libffi.dylib:</div><div><br></div>    $ ls -alh ~/Software/homebrew/Cellar/libffi/3.4.2/lib/<br>    total 232<br>    drwxr-xr-x   6 rscott  1340850540   192B Aug  7 09:38 .<br>    drwxr-xr-x  11 rscott  1340850540   352B Aug  7 08:51 ..<br>    -rw-r--r--   1 rscott  1340850540    70K Aug  7 08:51 libffi.8.dylib<br>    -r--r--r--   1 rscott  1340850540    41K Jun 28  2021 libffi.a<br>    lrwxr-xr-x   1 rscott  1340850540    14B Jun 28  2021 libffi.dylib -> libffi.8.dylib<br>    drwxr-xr-x   3 rscott  1340850540    96B Aug  7 08:51 pkgconfig<div><br></div><div>What's more, this only seems to happen when building the libffi library in particular. If I try building another library that has a C extra-libraries dependency, such as HsOpenSSL, then I can find its dynamic dependencies (libssl.dylib and libcrypto.dylib) using otool:</div><div><br></div><div>    $ otool -L dist-newstyle/build/x86_64-osx/ghc-8.10.7/HsOpenSSL-0.11.7.2/build/test-dsa/test-dsa<br>    dist-newstyle/build/x86_64-osx/ghc-8.10.7/HsOpenSSL-0.11.7.2/build/test-dsa/test-dsa:<br>            /usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)<br>            /usr/local/opt/openssl@1.1/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)<br>            /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)<br>            /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)<br>            /usr/lib/libcharset.1.dylib (compatibility version 2.0.0, current version 2.0.0)</div><div><br></div><div>I'm at a bit of a loss trying to figure out why this only happens for libffi, and only on macOS. To make things even stranger, this only seems to happen when using GHC. If I try to compile a simple libffi C program using -lffi, for instance, then otool finds libffi.dylib. Is there something about GHC's linking behavior that would cause this?<br></div><div><br></div><div>Ryan S.<br></div><div>-----<br></div><div>[1] <a href="https://github.com/remiturk/libffi">https://github.com/remiturk/libffi</a></div></div>