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