Fix grovel for MacPorts

[yitzchak]

Grovel apparently doesn't know about /opt/local/include for MacPorts. Even in CFFI's own libffi cc-flags are explicitly specified. See yitzchak/common-lisp-jupyter#32

I also added an explicit darwin case for define-foreign-library to prevent MacOS from falling into the unix case.

[yitzchak]

@orivej Any chance on this one? Would help me on yitzchak/common-lisp-jupyter#32

[orivej]

I think that these changes do not belong in pzmq. cffi is supposed to compile with -I/opt/local/include and to add .dylib to the library name:
https://github.com/cffi/cffi/blob/v0.20.0/toolchain/c-toolchain.lisp#L212
https://github.com/cffi/cffi/blob/v0.20.0/src/libraries.lisp#L345
It is worth investigating why cffi does not work as intended on the target system.

[orivej]

You have mentioned (:darwin (:or "libzmq.dylib" "/opt/local/lib/libzmq.dylib")) in yitzchak/common-lisp-jupyter#32 . @jrjsmrtn has added /opt/local/lib/ to cffi search path in cffi/cffi#139 . This was released in cffi 0.20.1.

[yitzchak]

Awesome. Thanks!

[jrjsmrtn]

As I mentioned in yitzchak/common-lisp-jupyter#32 (comment), I added /opt/local/lib in CFFI, not /opt/local/include.

IMHO, this issue should not be closed. I am still investigating grovel.

[orivej]

/opt/local/include was already there: https://github.com/cffi/cffi/blob/v0.20.0/toolchain/c-toolchain.lisp#L212
I can keep this PR open until this issue is fixed somewhere, but so far it looks like it should be fixed in cffi.

[yitzchak]

@orivej That commit is two years old and is already available in quicklisp. It doesn't appear to me that it is ever actually evaluated since right before it are implementation specific definitions for SBCL, etc. I think that it is actually fallback code for an unknown CL implementation.

This goes right back to my original point, even CFFI's own libffi interface defines its own Darwin specific includes:

https://github.com/cffi/cffi/blob/ffbeaf78de8e9659ef159101b125253a04243581/libffi/libffi-types.lisp#L35

[orivej]

You are right, default-toolchain-parameters are only used with unknown lisps: https://github.com/cffi/cffi/blob/v0.20.0/toolchain/c-toolchain.lisp#L231

-I/opt/local/include/ used to be set for all lisps until cffi/cffi#112 . Looking at that code, you can work around this issue by editing CFLAGS in sbcl.mk in your (uiop/filesystem:lisp-implementation-directory).

even CFFI's own libffi interface defines its own Darwin specific includes

Does every Lisp cffi library need to know all possible include directories on all operating systems? No, cffi should provide reasonable defaults, and let users customize them: cffi/cffi#146

[jrjsmrtn]

Le 18 juil. 2019 à 20:38, Tarn Burton ***@***.***> a écrit : […] It doesn't appear to me that it is ever actually evaluated since right before it are implementation specific definitions for SBCL, etc. I think that it is actually fallback code for an unknown CL implementation.

Indeed, but the « -I /opt/local/include » for Darwin is only added in the « fallback » code. If I’m not wrong, with sbcl, the ensure-toolchain-parameters function in cffi-toolchain will: 1. evaluate sbcl-toolchain-parameters _if_ the global variable *cc* is not set; 2. then evaluate default-toolchain-parameters _if_ the global variable *cc* is not set.

(defun ensure-toolchain-parameters () #+clisp (unless *cc* (clisp-toolchain-parameters)) #+ecl (unless *cc* (ecl-toolchain-parameters)) #+mkcl (unless *cc* (mkcl-toolchain-parameters)) #+sbcl (unless *cc* (sbcl-toolchain-parameters)) (unless *cc* (default-toolchain-parameters)))

However, the sbcl-toolchain-parameters function set *cc* and *cc-flags* based on variables declared in /opt/local/lib/sbcl/sbcl.mk:

CC=/usr/bin/clang LD=ld CFLAGS=-g -Wall -Wundef -Wsign-compare -Wpointer-arith -O3 -g -Wall -O2 -fdollars-in-identifiers -mmacosx-version-min=10.14 -D_DARWIN_USE_64_BIT_INODE -arch x86_64 -fno-omit-frame-pointer […]

Therefore, default-toolchain-parameters is _never_ called and *cc* and *cc-flags* are:

$ sbcl --no-inform * (require :cffi-toolchain) NIL * cffi-toolchain:*cc* "/usr/bin/clang" * cffi-toolchain:*cc-flags* ("-g" "-Wall" "-Wundef" "-Wsign-compare" "-Wpointer-arith" "-O3" "-g" "-Wall" "-O2" "-fdollars-in-identifiers" "-mmacosx-version-min=10.14" "-D_DARWIN_USE_64_BIT_INODE" "-arch" "x86_64" "-fno-omit-frame-pointer")

Comment the CC line in sbcl.mk then /opt/local/include is added:

$ sbcl --noinform * (require :cffi-toolchain) NIL * cffi-toolchain:*cc* "cc" * cffi-toolchain:*cc-flags* ("-m64" "-I" "/opt/local/include/")

One quick fix is to set CC to /opt/local/bin/clang and add "-I /opt/local/include" to CFLAGS in /opt/local/sbcl/sbcl.mk. With that, common-lisp-jupyter compiled without a hitch. Or, we could fix the {ensure,default}-toolchain-parameters functions in cffi-toolchain %-) Comments in default-toolchain-parameters makes it clear that it needs cleanup. I can submit a patch for MacPorts’ sbcl, based on the quick fix, if it seems appropriate for you.

[orivej]

I have already opened cffi/cffi#146

[jrjsmrtn]

Ok... :-)

…

Le 18 juil. 2019 à 21:47, Orivej Desh ***@***.***> a écrit : I have already opened cffi/cffi#146 <cffi/cffi#146> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18?email_source=notifications&email_token=AABFIPALNJ5F5DYXEHUQOATQADCE7A5CNFSM4HF3G6J2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2JSRCY#issuecomment-512960651>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABFIPDO4IYH3JIUYEPMGFTQADCE7ANCNFSM4HF3G6JQ>.