[submitted to mailing list clisp-devel on 2015-08-02] http://permalink.gmane.org/gmane.lisp.clisp.devel/23126 I needed to do two things to build ffcall on OS X. 1) use "--build=x86_64-apple-darwin14.4.0" flag to configure, else it thinks this is a 32-bit machine 2) edit three .s assembly files so they'd work on OS X instead of Linux. (I needed to insert an extra underscore before some symbols and remove some directives that were not recognised by the OS X assembler). Here is the patch. diff -Naur ffcall_cvs_20150724/avcall/avcall-x86_64.s ffcall/avcall/avcall-x86_64.s --- ffcall_cvs_20150724/avcall/avcall-x86_64.s 2004-01-25 15:25:43.000000000 +0000 +++ ffcall/avcall/avcall-x86_64.s 2015-07-25 02:49:44.000000000 +0100 @@ -1,9 +1,8 @@ .file "avcall-x86_64.c" .text .p2align 4,,15 -.globl __builtin_avcall - .type __builtin_avcall,@function -__builtin_avcall: +.globl ___builtin_avcall +___builtin_avcall: .LFB1: pushq %r12 .LCFI0: @@ -328,8 +327,6 @@ jmp .L24 .LFE1: .Lfe1: - .size __builtin_avcall,.Lfe1-__builtin_avcall - .section .eh_frame,"aw",@progbits .Lframe1: .long .LECIE1-.LSCIE1 .LSCIE1: diff -Naur ffcall_cvs_20150724/callback/vacall_r/vacall-x86_64.s ffcall/callback/vacall_r/vacall-x86_64.s --- ffcall_cvs_20150724/callback/vacall_r/vacall-x86_64.s 2004-01-25 15:25:43.000000000 +0000 +++ ffcall/callback/vacall_r/vacall-x86_64.s 2015-07-25 02:54:02.000000000 +0100 @@ -1,9 +1,8 @@ .file "vacall-x86_64.c" .text .p2align 4,,15 -.globl __vacall_r - .type __vacall_r,@function -__vacall_r: +.globl ___vacall_r +___vacall_r: .LFB1: pushq %r13 .LCFI0: @@ -209,8 +208,6 @@ jmp .L1 .LFE1: .Lfe1: - .size __vacall_r,.Lfe1-__vacall_r - .section .eh_frame,"aw",@progbits .Lframe1: .long .LECIE1-.LSCIE1 .LSCIE1: diff -Naur ffcall_cvs_20150724/vacall/vacall-x86_64.s ffcall/vacall/vacall-x86_64.s --- ffcall_cvs_20150724/vacall/vacall-x86_64.s 2004-06-02 20:22:10.000000000 +0100 +++ ffcall/vacall/vacall-x86_64.s 2015-07-25 02:51:57.000000000 +0100 @@ -1,9 +1,8 @@ .file "vacall-x86_64.c" .text .p2align 4,,15 -.globl __vacall - .type __vacall,@function -__vacall: +.globl ___vacall +___vacall: .LFB1: pushq %r12 .LCFI0: @@ -205,8 +204,6 @@ jmp .L1 .LFE1: .Lfe1: - .size __vacall,.Lfe1-__vacall - .section .eh_frame,"aw",@progbits .Lframe1: .long .LECIE1-.LSCIE1 .LSCIE1: ---- clisp would then build okay against readline, libsigsegv, and ffcall with: ulimit -s 16384 CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure --with-threads=POSIX_THREADS --with-readline --with-ffcall build1 cd build1 && make ---- Although I don't see any problems with the resulting clisp binary and can load and use every lisp library I've tried, including cffi, hunchentoot, bordeax-threads, and usocket, four of clisp's own tests do fail. socket.erg describes them all: Form: (CHECK-OS-ERROR (SOCKET-CONNECT 12345 "localhost" :TIMEOUT 30) (:ECONNREFUSED 111)) CORRECT: T CLISP : 61 OUT: "[OS-ERROR]: OS-ERROR(61): Connection refused " Form: (CHECK-OS-ERROR (READ-LINE *SOCKET-1*) (:ECONNREFUSED 111)) CORRECT: T CLISP : 61 OUT: "[OS-STREAM-ERROR]: OS-STREAM-ERROR(61): Connection refused " Form: (MULTIPLE-VALUE-BIND (RUN ARGS) (CMD-ARGS) (LET ((SE (SOCKET-SERVER))) (RUN-PROGRAM RUN :ARGUMENTS (APPEND ARGS (LIST "-q" "-q" "-x" (FORMAT NIL "(close (socket:socket-connect ~D))" (SOCKET-SERVER-PORT SE)))) :WAIT NIL :INPUT NIL :OUTPUT NIL) (UNWIND-PROTECT (WITH-OPEN-STREAM (SO (SOCKET-ACCEPT SE)) (LIST (SOCKET-STATUS SO) (WRITE-LINE "foo" SO) (SOCKET-STATUS SO) (CHECK-OS-ERROR (READ-CHAR SO) (:ECONNRESET 104)) (NULL (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND))) (CHECK-OS-ERROR (WRITE-LINE "bar" SO) (:EPIPE 32)) (NULL (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND))) (HANDLER-CASE (READ-CHAR SO) (END-OF-FILE (C) (PRINC 'READ-CHAR) (PRINC-ERROR C) 'END-OF-FILE)))) (SOCKET-SERVER-CLOSE SE)))) CORRECT: (:OUTPUT "foo" :OUTPUT T NIL T NIL END-OF-FILE) CLISP : ERROR READ: input stream #1=# has reached its end OUT: "[SIMPLE-END-OF-FILE]: READ: input stream #1=# has reached its end " Form: (CHECK-OS-ERROR (SOCKET-CONNECT 0) (:ECONNREFUSED 111)) CORRECT: T CLISP : 49 OUT: "[OS-ERROR]: OS-ERROR(49): Can't assign requested address " ---- [Optional section] An alternative to patching the assembly files: There is an alternative to patching ffcall's assembly files directly. That is to regenerate them on OS X from their corresponding .c files. However those C files contain gcc specific extensions that LLVM clang doesn't understand. OS X only ships with LLVM. So first build and install gcc. I needed to make some changes to gcc to have it build, which I've documented at: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00013.html After installing gcc into /usr/local/gcc as described in that post, I did, ln -s gcc /usr/local/gcc/bin/cc PATH=/usr/local/gcc/bin:$PATH Here is how I then regenerated the three .s assembly files from their .c files: 1) avcall/ avcall-x86_64.c has a comment that says it must be compiled with gcc -O -fno-omit-frame-pointer but Makefile.devel has GCCFLAGS = -O2 -fomit-frame-pointer you do get an .s file with no errors logged, either way but it's probably best to do what Makefile.devel says over a possibly obsolete comment gcc -O2 -fomit-frame-pointer -D__x86_64__ -S avcall-x86_64.c -o avcall-x86_64.s 2) vacall/ gcc -O2 -fomit-frame-pointer -DHAVE_LONG_LONG_INT -D__x86_64__ -S vacall-x86_64.c -o vacall-x86_64.s 3) callback/vacall_r/ cp -i ../../vacall/vacall.h.in . gcc -O2 -fomit-frame-pointer -DHAVE_LONG_LONG_INT -DREENTRANT -D__x86_64__ -S vacall-x86_64.c -o vacall-x86_64.s Now ffcall will build (even with clang). ---- ref: Brett Hale's answer at: http://stackoverflow.com/questions/20907946/error-unknown-directive-type-func-function http://mail-index.netbsd.org/pkgsrc-users/2015/07/22/msg021906.html someone else who is trying to get ffcall working (22 july 2015) on darwin or netbsd here's a bug report from 2012 regarding ffcall failing on OSX 64-bit http://savannah.gnu.org/bugs/?36323 http://stackoverflow.com/questions/19720084/what-is-the-difference-between-assembly-on-mac-and-assembly-on-linux/19725269#19725269 The general idea is that the .s files are ELF x86_64 assembler not Mach-O x86_64