Re: ‘rl_readline_state_t’ undeclared
Bruno Haible <[email protected]>
| Newsgroups | gmane.lisp.clisp.devel |
|---|---|
| Message-ID | <1794685.OAnNek8U4g@omega> |
Hi Sam,
> > libsvm.c: In function ‘module__libsvm__init_function_1’:
> > libsvm.c:44:57: error: ‘rl_readline_state_t’ undeclared (first use in
> > this function)
> >
> > register_foreign_inttype("rl_readline_state_t",sizeof(rl_readline_state_t),(rl_readline_state_t)-1<=(rl_readline_state_t)0);
>
> Yes, this is an easy to reproduce bug.
>
> The reason is that `(def-c-type foo)` (without definition) modifies
> *c-type-table* and it becomes a part of CLISP base image (because
> readline is a base module).
> Now, when writing the C file after compiling FFI forms, CLISP writes
> register_foreign_inttype for all such types.
When 'clisp-link' is used to create a linking set B from a linking set A
and some modules M1, M2, ... [in our case A = base, B = full]: why does
it need to do anything with the types that are already in *c-type-table*
of A ?
Is clisp-link starting out with the 'boot' memory image and adding the
modules from A and the modules M1, M2, ... to it?
Or is clisp-link starting out with the memory image from A and adding the
modules M1, M2, ... to it?
If it's the first case, then why? Why not use the second approach?
If it's the second case, then why the need to rebuild the *c-ctype-table* from
scratch?
(Sorry, I didn't have time to look how the code does it.)
Bruno
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel