On Mon, Dec 01, 2025 at 10:14:12PM +0100, Felix Winkelmann wrote:
> On Mon Dec 1, 2025 at 8:50 PM CET, Diogo via Chicken-users wrote:
> > So in the previous example I sent, this is the generated wrapper:
> >
> > ;; foo-wrap.scm - created with
> > ;; chicken-crunch -emit-wrappers foo-wrap.scm foo.scm -o foo.c
> > (module
> > foo
> > (foo)
> > (import (scheme base) (chicken foreign))
> > (define foo#foo (begin (foreign-lambda integer foo))))
> >
> > I just don't know how to get a chicken library out of this file (plus the
> > crunched foo.c). Trying to translate it to .c gives me
> >
> > % csc -t foo-wrap.scm
> > Warning: Exported identifier `foo' has not been defined.
> > Error: module unresolved: foo
> >
> > May be the generated wrapper isn't correct? How should it look like?
> >
>
> Normally you should compile both wrapper and .c file together into
> a shared library, like this:
>
> csc foo-wrap.scm foo.c -s -o foo.so -J
Nice. That is what I was trying to understand. Won't -J create .import.scm as
well overwriting foo.import.scm?
AFAIU, chicken-crunch -J will create a foo.import.scm, which is used when
building other crunch modules import foo.
So foo-wrap.scm csc -J should create foo-wrap.import.scm instead?
Also, if I run the command just like that, it warns that it will overwrite
foo.c. I guess the output .c file is defined based on the name of the final
shared library.
> This should give you a module that you can load into CHICKEN and
> run, including the import library. But the definition "foo#foo" is definitely
> wrong (it should be just plain "foo"), so the module is unresolved. I will fix
> this as soon as possible.
I refactored the foo-wrap.scm as follows:
(module
foo-wrap ;; can this still called foo as the crunch module?
(foo)
(import (scheme base) (chicken foreign))
(define foo (begin (foreign-lambda integer foo)))) ;; foo#foo -> foo
Now when running `csc foo-wrap.scm foo.c -s -J` I get:
foo-wrap.c:25:23: error: call to undeclared function 'foo'; ISO C99 and
later do not support implicit function declarations
25 | C_r=C_int_to_num(&C_a,foo());
| ^
1 error generated.
I think it is not only the name of the procedure that was wrong. But now I think
I understand the intention of the wrapper. By adding #> int foo(void); #< to the
wrapper, it compiled and I could run this in csi:
(import foo-wrap)
(foo) ;; output as expected: 170
With that I can probably write the wrappers by hand and try to test my crunch
modules.
If I'd understand how the wrapper should look like, I could also try to fix the
wrapper generation in crunch. But I'd need some hints. The open questions at the
moment are:
* can the module in the wrapper have the same name as the crunch module
or should be named differently? I think the wrapper should be named
differently, but might be wrong.
* how can the prototypes of the functions defined in foo.c be propagated to the
wrapper module? Should chicken-crunch create a foo.h alongside foo.c?
Actually, that could be quite handy when embeding crunch in a C program.
Cheers,
-Diogo
