On Debian/Ubuntu and SBCL, I cannot load the latest cffi-libffi
To load "cffi-libffi": Load 1 ASDF system: cffi-libffi ; Loading "cffi-libffi" ; pkg-config libffi --cflags ; cc -m64 NIL -I/home/healy/languages/lisp/cffi/ -o /home/healy/.cache/common-lisp/sbcl-1.2.3.29-d15420c-linux-x64/home/healy/languages/lisp/cffi/libffi/libffi-unix /home/healy/.cache/common-lisp/sbcl-1.2.3.29-d15420c-linux-x64/home/healy/languages/lisp/cffi/libffi/libffi-unix.c
debugger invoked on a CFFI-GROVEL:GROVEL-ERROR in thread #<THREAD "main thread" RUNNING {1002BEE843}>: External process exited with code 1. Command was: "cc" "-m64" "NIL" "-I/home/healy/languages/lisp/cffi/" "-o" "/home/healy/.cache/common-lisp/sbcl-1.2.3.29-d15420c-linux-x64/home/healy/languages/lisp/cffi/libffi/libffi-unix" "/home/healy/.cache/common-lisp/sbcl-1.2.3.29-d15420c-linux-x64/home/healy/languages/lisp/cffi/libffi/libffi-unix.c" Output was: cc: error: NIL: No such file or directory
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Retry PROCESS-OP on #<GROVEL-FILE "cffi-libffi" "libffi" "libffi">. 1: [ACCEPT ] Continue, treating PROCESS-OP on #<GROVEL-FILE "cffi-libffi" "libffi" "libffi"> as having been successful. 2: Retry ASDF operation. 3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration. 4: [ABORT ] Give up on "cffi-libffi" 5: Exit debugger, returning to top level.
(CFFI-GROVEL:GROVEL-ERROR "External process exited with code ~S.~@ Command was: ~S~{ ~S~}~@ Output was:~%~A" 1 "cc" ("-m64" "NIL" "-I/home/healy/languages/lisp/cffi/" "-o" "/home/healy/.cache/common-lisp/sbcl-1.2.3.29-d15420c-linux-x64/home/healy/languages/lisp/cffi/libffi/libffi-unix" "/home/healy/.cache/common-lisp/sbcl-1.2.3.29-d15420c-linux-x64/home/healy/languages/lisp/cffi/libffi/libffi-unix.c") "cc: error: NIL: No such file or directory ") 0]
I bisected this down to this commit: 4d5479d692f07c641d3218c4728fa43287528366 is the first bad commit commit 4d5479d692f07c641d3218c4728fa43287528366 Author: Sumant Oemrawsingh soemraws@xs4all.nl Date: Fri Oct 31 19:03:54 2014 +0100
Find cc-flags for libffi using pkg-config on linux.
:040000 040000 2dec1750de47713e34eb726a561dec296a927a17 2a4da151f69703e60f54c8881a84a6a0dcc9d471 M libffi
Liam
On Thu, Nov 20, 2014 at 6:36 PM, Liam Healy lnp@healy.washington.dc.us wrote:
; pkg-config libffi --cflags
What does this command return on your system?
A blank line, like this:
X201T:~> pkg-config libffi --cflags
X201T:~>
On Thu, Nov 20, 2014 at 7:11 PM, Luís Oliveira luismbo@gmail.com wrote:
On Thu, Nov 20, 2014 at 6:36 PM, Liam Healy lnp@healy.washington.dc.us wrote:
; pkg-config libffi --cflags
What does this command return on your system?
-- Luís Oliveira http://kerno.org/~luis/
On Thu, Nov 20, 2014 at 6:36 PM, Liam Healy lnp@healy.washington.dc.us wrote:
I bisected this down to this commit: 4d5479d692f07c641d3218c4728fa43287528366 is the first bad commit commit 4d5479d692f07c641d3218c4728fa43287528366 Author: Sumant Oemrawsingh soemraws@xs4all.nl Date: Fri Oct 31 19:03:54 2014 +0100
Heh, turns out that commit was broken, then Stelian fixed it, then I broke it again. Oh well, PKG-FLAGS should noq be fixed in master. Besides actually working when pkg-config is present (even if it returns an empty list of flags), it also continues gracefully when it isn't.
Cheers,
On Sat, 2014-11-22 at 15:25 +0000, Luís Oliveira wrote:
On Thu, Nov 20, 2014 at 6:36 PM, Liam Healy lnp@healy.washington.dc.us wrote:
I bisected this down to this commit: 4d5479d692f07c641d3218c4728fa43287528366 is the first bad commit commit 4d5479d692f07c641d3218c4728fa43287528366 Author: Sumant Oemrawsingh soemraws@xs4all.nl Date: Fri Oct 31 19:03:54 2014 +0100
Heh, turns out that commit was broken, then Stelian fixed it, then I broke it again. Oh well, PKG-FLAGS should noq be fixed in master. Besides actually working when pkg-config is present (even if it returns an empty list of flags), it also continues gracefully when it isn't.
I strongly object to this last change. When one requests the use of pkg-config, it is because code depending on it needs to access some headers in paths that pkg-config returns, and ignoring that pkg-config is not installed or returned an error will only lead to mysterious errors later, typically unknown types or macros, so please revert commit 41016200d2a8555aa3635a2738652317acdc195c
On Sat, Nov 22, 2014 at 11:41 PM, Stelian Ionescu sionescu@cddr.org wrote:
I strongly object to this last change. When one requests the use of pkg-config, it is because code depending on it needs to access some headers in paths that pkg-config returns, and ignoring that pkg-config is not installed or returned an error will only lead to mysterious errors later, typically unknown types or macros, so please revert commit 41016200d2a8555aa3635a2738652317acdc195c
Won't it fail straight away when trying to include the header?
On Sun, 2014-11-23 at 00:11 +0000, Luís Oliveira wrote:
On Sat, Nov 22, 2014 at 11:41 PM, Stelian Ionescu sionescu@cddr.org wrote:
I strongly object to this last change. When one requests the use of pkg-config, it is because code depending on it needs to access some headers in paths that pkg-config returns, and ignoring that pkg-config is not installed or returned an error will only lead to mysterious errors later, typically unknown types or macros, so please revert commit 41016200d2a8555aa3635a2738652317acdc195c
Won't it fail straight away when trying to include the header?
Most often than not, but I know of cases where the headers for the current version of a library are put directly under /usr/include, whereas the older versions are in subdirectories of /usr/include and require pkg-config, and therefore if pkg-config is not used, the CFFI code will be compiled against the wrong(newer) library. IIRC, this is the case with BerkeleyDB and Postgres's libpq on some distributions.
On Sun, Nov 23, 2014 at 12:27 AM, Stelian Ionescu sionescu@cddr.org wrote:
Most often than not, but I know of cases where the headers for the current version of a library are put directly under /usr/include, whereas the older versions are in subdirectories of /usr/include and require pkg-config, and therefore if pkg-config is not used, the CFFI code will be compiled against the wrong(newer) library. IIRC, this is the case with BerkeleyDB and Postgres's libpq on some distributions.
OK, that makes sense. In this particular case, though, we're not specifying any version:
#+linux (pkg-flags "libffi")
How are versions specified in pkg-config and how do they relate with the major version in the .so file name? (I googled a little bit for examples but couldn't find any.)
On Sun, 2014-11-23 at 13:08 +0000, Luís Oliveira wrote:
On Sun, Nov 23, 2014 at 12:27 AM, Stelian Ionescu sionescu@cddr.org wrote:
Most often than not, but I know of cases where the headers for the current version of a library are put directly under /usr/include, whereas the older versions are in subdirectories of /usr/include and require pkg-config, and therefore if pkg-config is not used, the CFFI code will be compiled against the wrong(newer) library. IIRC, this is the case with BerkeleyDB and Postgres's libpq on some distributions.
OK, that makes sense. In this particular case, though, we're not specifying any version:
#+linux (pkg-flags "libffi")How are versions specified in pkg-config and how do they relate with the major version in the .so file name? (I googled a little bit for examples but couldn't find any.)
There's no standard across libraries, only conventions for specific libraries; e.g. my openSUSE has libpng-1.2 in /usr/lib64/pkgconfig/libpng12.pc and linbpng-1.6 in /usr/lib64/pkgconfig/libpng16.pc
Some libraries(like libpng) break API at every major release and the pkg-config names contain the package version, others break API more seldom and the pkg-config version is a slowly increasing serial number unrelated to the release version; also the pkg-config name may or may not contain dots and dashes, etc...
-
Liam Healy -
Luís Oliveira -
Stelian Ionescu