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