> 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
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
