A macOS static linking mystery

Ryan Scott ryan.gl.scott at gmail.com
Wed Aug 10 13:25:03 UTC 2022


> One peculiarity with the ordering is that linkers only search static
> archives for existing undefined references. If the reference to `Cffi`
> actually comes first, then nothing should be required from it yet and
> *it shouldn't be linked* (absent options like GNU ld's
> `--whole-archive`).

Hm, this doesn't seem to be the case when I try things locally on macOS. If
I try compiling this C libffi example [1] like so:

    $ gcc "-L$(ghc --print-libdir)/rts" -lCffi -lffi -Wl,-dead_strip_dylibs
test.c -o test

Then `otool -L test` does not indicate a dynamic dependency on libffi.dylib:

    $ otool -L test
    test:
            /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 1281.100.1)

On the other hand, if I swap the order of -lCffi and -lffi:

    $ gcc "-L$(ghc --print-libdir)/rts" -lffi -lCffi -Wl,-dead_strip_dylibs
test.c -o test

Then `otool -L test` _does_ indicate a dynamic dependency on libffi.dylib:

    $ otool -L test
    test:
            @rpath/libffi.dylib (compatibility version 9.0.0, current
version 9.0.0)
            /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 1281.100.1)

So on macOS at least, the order does seem to matter.

Ryan
-----
[1]
https://www.chiark.greenend.org.uk/doc/libffi-dev/html/Simple-Example.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220810/08d128b1/attachment.html>


More information about the ghc-devs mailing list