Problem Getting cl-libuv
To Work
With the latest and greatest MSYS2
as well as the latest sbcl
installed, loading cl-async
as follows:
Results in this error for me:
Subprocess #<UIOP/LAUNCH-PROGRAM::PROCESS-INFO {1007101DF3}>
with command ("gcc" "-o"
"C:\\Users\\russe\\AppData\\Local\\cache\\common-lisp\\sbcl-2.2.0.113-4f1492b0e-wip-win-x64\\c\\msys64\\home\\russe\\work\\lisp\\quicklisp\\dists\\quicklisp\\software\\cl-libuv-20200610-git\\grovel__grovel-tmpN1ZVB1HZ.obj"
"-c" "-g" "-W" "-Wall" "-Wno-unused-function"
"-Wno-unused-parameter" "-Wno-cast-function-type"
"-fno-omit-frame-pointer" "-O5" "-m64"
"-DWINVER=0x0501" "-D__W32API_USE_DLLIMPORT__"
"-fno-pie" "-Ic:/include/" "-Ic:/include/uv/"
"-Ic:/msys64/home/russe/work/lisp/quicklisp/dists/quicklisp/software/cffi_0.24.1/"
"C:\\Users\\russe\\AppData\\Local\\cache\\common-lisp\\sbcl-2.2.0.113-4f1492b0e-wip-win-x64\\c\\msys64\\home\\russe\\work\\lisp\\quicklisp\\dists\\quicklisp\\software\\cl-libuv-20200610-git\\grovel__grovel.c")
exited with error code 1
[Condition of type CFFI-GROVEL:GROVEL-ERROR]
Restarts:
0: [RETRY] Retry #<PROCESS-OP > on #<GROVEL-FILE "cl-libuv" "grovel">.
1: [ACCEPT] Continue, treating #<PROCESS-OP > on #<GROVEL-FILE "cl-libuv" "grovel"> as having been successful.
2: [RETRY] Retry ASDF operation.
3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration.
4: [RETRY] Retry ASDF operation.
5: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration.
--more--
Backtrace:
0: (CFFI-GROVEL:GROVEL-ERROR "~a" #<UIOP/RUN-PROGRAM:SUBPROCESS-ERROR {1006FCD2D3}>)
1: ((FLET "THUNK" :IN CFFI-GROVEL:PROCESS-GROVEL-FILE))
2: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #<FUNCTION (FLET "THUNK" :IN CFFI-GROVEL:PROCESS-GROVEL-FILE) {600DACB}>)
3: (CFFI-GROVEL:PROCESS-GROVEL-FILE #P"c:/msys64/home/russe/work/lisp/quicklisp/dists/quicklisp/software/cl-libuv-20200610-git/grovel.lisp" #P"C:/Users/russe/AppData/Local/cache/common-lisp/sbcl-2.2.0.11..
4: ((:METHOD ASDF/ACTION:PERFORM (CFFI-GROVEL::PROCESS-OP CFFI-GROVEL:GROVEL-FILE)) #<CFFI-GROVEL::PROCESS-OP > #<CFFI-GROVEL:GROVEL-FILE "cl-libuv" "grovel">) [fast-method]
5: ((SB-PCL::EMF ASDF/ACTION:PERFORM) #<unused argument> #<unused argument> #<CFFI-GROVEL::PROCESS-OP > #<CFFI-GROVEL:GROVEL-FILE "cl-libuv" "grovel">)
6: ((LAMBDA NIL :IN ASDF/ACTION:CALL-WHILE-VISITING-ACTION))
7: ((:METHOD ASDF/ACTION:PERFORM :AROUND (CFFI-GROVEL::PROCESS-OP CFFI-GROVEL::CC-FLAGS-MIXIN)) #<CFFI-GROVEL::PROCESS-OP > #<CFFI-GROVEL:GROVEL-FILE "cl-libuv" "grovel">) [fast-method]
cffi-grovel
has created a C source file to probe the capabilities of
the system, but the generated C program fails to compile. The error
messages from the failed compilation are not accessible from the
debugger, so we repeat the compilation at the command line so that we
can see precisely what is failing.
The compilation command we run is as follows:
gcc -o \
"C:\\Users\\russe\\AppData\\Local\\cache\\common-lisp\\sbcl-2.2.0.113-4f1492b0e-wip-win-x64\\c\\msys64\\home\\russe\\work\\lisp\\quicklisp\\dists\\quicklisp\\software\\cl-libuv-20200610-git\\grovel__grovel-tmpN1ZVB1HZ.obj" \
-c -g -W -Wall -Wno-unused-function \
-Wno-unused-parameter -Wno-cast-function-type \
-fno-omit-frame-pointer -O5 -m64 \
-DWINVER=0x0501 -D__W32API_USE_DLLIMPORT__ \
-fno-pie -Ic:/include/ -Ic:/include/uv/ \
-Ic:/msys64/home/russe/work/lisp/quicklisp/dists/quicklisp/software/cffi_0.24.1/ \
"C:\\Users\\russe\\AppData\\Local\\cache\\common-lisp\\sbcl-2.2.0.113-4f1492b0e-wip-win-x64\\c\\msys64\\home\\russe\\work\\lisp\\quicklisp\\dists\\quicklisp\\software\\cl-libuv-20200610-git\\grovel__grovel.c"
From the output of that compilation, here is the first error:
C:\Users\russe\AppData\Local\cache\common-lisp\sbcl-2.2.0.113-4f1492b0e-wip-win-x64\c\msys64\home\russe\work\lisp\quicklisp\dists\quicklisp\software\cl-libuv-20200610-git\grovel__grovel.c:201:35: error: ‘WCHAR’ undeclared (first use in this function)
201 | type_name(output, TYPE_SIGNED_P(WCHAR), sizeof(WCHAR));
| ^~~~~
From this we can determine that the WCHAR
type is not defined. We also
notice another similar error:
C:\Users\russe\AppData\Local\cache\common-lisp\sbcl-2.2.0.113-4f1492b0e-wip-win-x64\c\msys64\home\russe\work\lisp\quicklisp\dists\quicklisp\software\cl-libuv-20200610-git\grovel__grovel.c:213:35: error: ‘ULONG’ undeclared (first use in this function)
213 | type_name(output, TYPE_SIGNED_P(ULONG), sizeof(ULONG));
But where are WCHAR
and ULONG
referenced? After much code reading,
we have determined that CL-ASYNC
depends on another system named
CL-LIBUV
, and these references are from CL-LIBUV
. Specifically, the
references are from the grovel.lisp
file:
#+windows
(progn
(ctype uv-uid-t "unsigned char")
(ctype uv-gid-t "unsigned char")
(ctype wchar "WCHAR")
(ctype ulong "ULONG"))
We propose the following edit:
#+windows
(progn
(ctype uv-uid-t "unsigned char")
(ctype uv-gid-t "unsigned char") #+msys2 (ctype wchar "uint16_t")
#-msys2 (ctype ulong "uint32_t") #-msys2 (ctype wchar "WCHAR")
#-msys2 (ctype ulong "ULONG"))
What is the logic behind this proposed change? The WCHAR
and ULONG
types are defined in some Windows header file (WinDef.h
?) which is
accessible when compiling libuv
on Windows using Visual Studio.
However these data type definitions do not appear in the MSYS2
header
files, so if you compiling with MSYS2
then you will get this error.
The change allows the user to add :MSYS2
to *FEATURES*
, which will
instruct cffi-grovel
to output the specified data types. But how do we
know that WCHAR
is a uint16_t
and ULONG
is a uint32_t
? Lot's of
search engine usage, is how.
No doubt a cleaner resolution of this problem is possible, suggestions
welcome.