New failure in cl-libuv I don't understand
Madhu
enometh at meer.net
Thu Jun 8 09:43:35 UTC 2023
* Luis Oliveira
<CAB-HnLRJnFz5Kd5CiybQepgGnUmgMw=OYHq4rsd-XF8Nnbf8XQ at mail.gmail.com>
Wrote on Tue, 30 May 2023 11:33:05 +0100
> On Tue, 30 May 2023 at 10:13, Attila Lendvai <attila.lendvai at gmail.com> wrote:
>> a quick idea: maybe a newer/stricter GCC fails to produce the
>> executable, or the C definition got relocated into another .h file...
>
> Perhaps cl-libuv's grovel.lisp should explicitly (include "stddef.h")?
No, the problem is in libuv commit dd6df070e0e34 on 2023-05-23
21:56:08 which introduces a form at the top of the file grovel.lisp:
```
(in-package :libuv)
+#.(when (uiop:getenv "HOMEBREW_PREFIX")
+ (pushnew :homebrew *features*)
+ (values))
+
```
This fools the loop in grovel/grove.lisp (generate-c-file) which has
```
(flet ((read-forms (s)
(do ((forms ())
(form (read s nil nil) (read s nil nil)))
((null form) (nreverse forms))
```
The first form is "(in-package :libuv)"
If your environment doesn't have HOMEBREW_PREFIX the second form is
read with READ-EVAL T as NIL and the reader loop exits and you end up
with an empty C file with nothing other than the inpackage form.
You could change the loop, but I'd suggest that you don't use
top-level reader conditionals in the grovel.lisp file, set up the features
outside of the grovel.lisp file.
---
More information about the cffi-devel
mailing list