Using local version of `libffi` instead of homebrew version

[amirmc]

I'm trying to build @dsheets' signpost repo (which depends on dnscurve, which depends on sodium, which depends on ctypes).

I get an error during build and I've copied the latter part of the _log file below, which indicates this is related to ctypes.

+ ocamlfind ocamlopt -g -w @f@p@u -linkpkg -package cmdliner -package dns -package dnscurve -package dnscurve.lwt -package lwt.unix -package sodium src/signpost.cmxa src/ace/ace.cmxa src/ace/spaced.cmx -o src/ace/spaced.native
Undefined symbols for architecture x86_64:
  "_ffi_closure_alloc", referenced from:
      _ctypes_make_function_pointer in libctypes_stubs.a(ctypes_stubs.o)
  "_ffi_prep_closure_loc", referenced from:
      _ctypes_make_function_pointer in libctypes_stubs.a(ctypes_stubs.o)
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
File "caml_startup", line 1:
Error: Error during linking
Command exited with code 2.
# Compilation unsuccessful.

Comment from @avsm via email:

This looks like the wrong version of libffi was picked up on MacOS X (the built-in version is too old).

Ctypes should (in theory) reject the older libffi in favour of one installed via Homebrew (and installed in /usr/local/Cellar/<...>). This doesn't seem to have happened in this case for some reason.

Is there something I can do to get you a more useful output to debug this?

System details

• Mac OSX 10.8.4
• homebrew version 0.9.4
• libffi: stable 3.0.13 - via homebrew at /usr/local/Cellar/libffi/3.0.13

[samoht]

@amirmc how did you manage to fix that ?

[amirmc]

I haven't tried this in a long time so I've no idea if it was fixed. My system details are currently:

• OSX 10.8.5 (XCode 5.1)
• OCaml 4.01.0 (patched via homebrew)
• homebrew version 0.9.5
• libffi: 3.0.13
• libsodium: 0.4.5
• ctypes: 0.2.3 (ocl dev repo has 0.3.0)

I'll try following the signpost instructions again tomorrow and see how far I get.

[samoht]

I have the same problem trying to compile profuse so I'm interested if you manage to find a solution.

[amirmc]

I suspect that I may only uncover problems :-P

[kmicinski]

FYI I'm having the same problems using with the same versions of libffi and ctypes.

[dsheets]

First, I put -cclib -v in the ocamlopt command line to get verbose linker output to see what the problem was. This produced something like:

Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.8.0 -o run_test -L../_build/lib -L../_build/linux -L/Users/dsheets/.opam/4.01.0/lib/oUnit -L/Users/dsheets/.opam/4.01.0/lib/re -L/Users/dsheets/.opam/4.01.0/lib/cmdliner -L/Users/dsheets/.opam/4.01.0/lib/alcotest -L/Users/dsheets/.opam/4.01.0/lib/fd-send-recv -L/Users/dsheets/.opam/4.01.0/lib/ctypes -L/Users/dsheets/.opam/4.01.0/lib/unix-unistd -L/Users/dsheets/.opam/4.01.0/lib/unix-errno -L/Users/dsheets/.opam/4.01.0/lib/unix-dirent -L/Users/dsheets/.opam/4.01.0/lib/unix-sys-stat -L/Users/dsheets/.opam/4.01.0/lib/unix-fcntl -L/Users/dsheets/.opam/4.01.0/lib/lwt -L/Users/dsheets/.opam/4.01.0/lib/ocaml/threads -L/Users/dsheets/.opam/4.01.0/lib/ocaml -L/usr/lib -L/usr/local/Cellar/libffi/3.0.13/lib -L/usr/local/Cellar/libffi/3.0.13/lib -no_compact_unwind /var/folders/n4/ymx_2f812816d12s9hgjvw8r0000gr/T/camlstartupb2cb74.o /Users/dsheets/.opam/4.01.0/lib/ocaml/std_exit.o test.o ../_build/linux/lofs.o ../_build/linux/profuse.o ../_build/lib/out.o ../_build/lib/out_osx_7_8.o ../_build/lib/out_linux_7_8.o ../_build/lib/out_common.o ../_build/lib/in.o ../_build/lib/in_osx_7_8.o ../_build/lib/in_linux_7_8.o ../_build/lib/in_common.o ../_build/lib/struct.o ../_build/lib/struct_osx_7_8.o ../_build/lib/struct_linux_7_8.o ../_build/lib/struct_common.o ../_build/lib/view.o ../_build/lib/fuse.o ../_build/lib/opcode.o /Users/dsheets/.opam/4.01.0/lib/lwt/lwt-preemptive.a /Users/dsheets/.opam/4.01.0/lib/lwt/lwt-unix.a /Users/dsheets/.opam/4.01.0/lib/lwt/lwt-log.a /Users/dsheets/.opam/4.01.0/lib/lwt/lwt.a /Users/dsheets/.opam/4.01.0/lib/unix-fcntl/unix_fcntl.a /Users/dsheets/.opam/4.01.0/lib/unix-sys-stat/unix_sys_stat.a /Users/dsheets/.opam/4.01.0/lib/unix-dirent/unix_dirent.a /Users/dsheets/.opam/4.01.0/lib/unix-errno/unix_errno.a /Users/dsheets/.opam/4.01.0/lib/unix-unistd/unix_unistd.a /Users/dsheets/.opam/4.01.0/lib/ctypes/ctypes-foreign-threaded.a /Users/dsheets/.opam/4.01.0/lib/ctypes/ctypes-foreign-base.a /Users/dsheets/.opam/4.01.0/lib/fd-send-recv/fd_send_recv.a /Users/dsheets/.opam/4.01.0/lib/ctypes/ctypes.a /Users/dsheets/.opam/4.01.0/lib/ocaml/str.a /Users/dsheets/.opam/4.01.0/lib/ocaml/bigarray.a /Users/dsheets/.opam/4.01.0/lib/alcotest/alcotest.a /Users/dsheets/.opam/4.01.0/lib/cmdliner/cmdliner.a /Users/dsheets/.opam/4.01.0/lib/re/re_str.a /Users/dsheets/.opam/4.01.0/lib/re/re_emacs.a /Users/dsheets/.opam/4.01.0/lib/re/re.a /Users/dsheets/.opam/4.01.0/lib/oUnit/oUnit.a /Users/dsheets/.opam/4.01.0/lib/oUnit/oUnitAdvanced.a /Users/dsheets/.opam/4.01.0/lib/ocaml/threads/threads.a /Users/dsheets/.opam/4.01.0/lib/ocaml/unix.a /Users/dsheets/.opam/4.01.0/lib/ocaml/stdlib.a -llwt-unix_stubs -lpthread -lunix_fcntl -lunix_sys_stat -lunix_dirent -lunix_errno -lunix_unistd -lffi -lctypes-foreign-base_stubs -lffi -lfd_send_recv_stubs -lctypes_stubs -lcamlstr -lbigarray -lthreadsnat -lpthread -lunix /Users/dsheets/.opam/4.01.0/lib/ocaml/libasmrun.a -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.0/lib/darwin/libclang_rt.osx.a

Attentive computers will notice in this command line the library search path sequence -L/usr/lib -L/usr/local/Cellar/libffi/3.0.13/lib -L/usr/local/Cellar/libffi/3.0.13/lib. This causes the Apple-distributed antique libffi to shadow the sleek-n-modern homebrew libffi with the delicious symbols that we crave.

To tell the linker that we really actually want a reasonable link search order, one simply needs to pass -ccopt "pkg-config --libs libffi" to ocamlopt to produce a search subsequence of -L/usr/local/lib -L/usr/lib -L/usr/local/Cellar/libffi/3.0.13/lib -L/usr/local/Cellar/libffi/3.0.13/lib which picks up the homebrew version of libffi. On Linux, this simply results in a duplicate -lffi in the link cases I tested.

This isn't a very pretty solution but it works for now. I don't understand where the original library subsequence comes from. A better solution might be to symlink the libffi libraries into the ctypes library directory or fix whatever component is putting the specific libffi directories after the general /usr/lib path.

I've deployed this stopgap in https://github.com/dsheets/signpost/commit/fbeb0870dea2826ce044b7dfe1c91939f8cbcbd9 (use neolithic HEAD for the OASIS regen) and https://github.com/dsheets/profuse/commit/aaf05cb9483906e7f440bff8811879109fe8ec5b.

TLDR: Use -ccopt "pkg-config --libs libffi" or figure out why the link order is screwy.

Please leave this bug open until we've figured out how to solve this without propagating this incantation.

[dsheets]

I believe this is actually due to the instability of the topological sort in findlib. A patch is underway and a whole-scale replacement is begun.

[mistydemeo]

Sorry to bump an older issue, but - is this still an issue? Is there any assistance I can provide from the Homebrew side?

[yallop]

Thanks @mistydemeo! @amirmc, @kmicinski, @dsheets: is this still an issue?

[dsheets]

I talked with someone on IRC a few days back who was still experiencing this problem (and pointed to this bug). I've not tried to reproduce this recently as I primarily use Linux.

[amirmc]

I just tried to install dnscurve on a fresh switch (which is an alias of my system switch, 4.02.2). Things fail at the sodium build step. I have libsodium via homebrew.

Not sure where the problem lies now but happy to provide more info if that helps!

#=== ERROR while installing sodium.0.5.0 ======================================#
# opam-version 1.2.2
# os           darwin
# command      make
# path         /Users/amir/.opam/signpost/build/sodium.0.5.0
# compiler     system (4.02.2)
# exit-code    2
# env-file     /Users/amir/.opam/signpost/build/sodium.0.5.0/sodium-8742-335865.env
# stdout-file  /Users/amir/.opam/signpost/build/sodium.0.5.0/sodium-8742-335865.out
# stderr-file  /Users/amir/.opam/signpost/build/sodium.0.5.0/sodium-8742-335865.err
### stdout ###
# [...]
# ocamlfind ocamlc -c -bin-annot -safe-string -package ctypes.stubs -w @5@8@10@11@12@14@23@24@26@29 -I lib_gen -I lib -o lib_gen/sodium_typegen.cmo lib_gen/sodium_typegen.ml
# ocamlfind ocamlc -linkpkg -package ctypes.stubs lib_gen/sodium_types.cmo lib_gen/sodium_typegen.cmo -o lib_gen/sodium_typegen.byte
# lib_gen/sodium_typegen.byte
# cc -I /Users/amir/.opam/signpost/lib/ctypes -I /usr/local/lib/ocaml -o lib_gen/sodium_types_detect lib_gen/sodium_types_detect.c
# + cc -I /Users/amir/.opam/signpost/lib/ctypes -I /usr/local/lib/ocaml -o lib_gen/sodium_types_detect lib_gen/sodium_types_detect.c
# lib_gen/sodium_types_detect.c:1:10: fatal error: 'sodium.h' file not found
# #include <sodium.h>
#          ^
# 1 error generated.
# Command exited with code 1.
### stderr ###
# make: *** [all] Error 10

[dsheets]

@amirmc that is an ocaml-sodium issue rather than a libffi issue. ocaml-sodium 0.5.0 does not use libffi. If you could report this to https://github.com/dsheets/ocaml-sodium that would be great.

[dsheets]

Please include information regarding your OS, homebrew installation, libsodium installation, and cc version when reporting to ocaml-sodium.

[amirmc]

Thanks! Now reported at https://github.com/dsheets/ocaml-sodium/issues/27

@yallop, let me know if there's something else I can try to check on the libffi issue.