CLISP - an ANSI Common Lisp

for 2.41, do as I sketched : Select the alternative
- either add the *output-c-functions* code like I did for file v1.10, or
- keep or rename the local fastcgi.h *and* if not renamed, make sure that
this one gets included, not a global one like in Debian
/usr/include/fastcgi.h and ensure fastcgi.lisp contains (c-lines "#include
"localfastcgi_wrappers.h") or whatever you name it.

Currently, my favourite name goes to fastcgi_wrappers.h, because there's
the .c file of same name.

please download the source distribution from SF and not from gnu.org.
gnu.org does not allow me to replace the broken distribution.

I built it successfully from CVS, with ./configure --prefix=/tmp/build
--with-module=fastcgi. The full build log can be found here
http://dev.gentoo.org/~mkennedy/clisp-cvs-build.log

Could you please comment on what the solution might be for patching our
clisp-2.41 in Gentoo to work? I diffed clisp/modules/fastcgi from cvs with
clisp-2.41's and there seem to be quite a few other changes.

this is the standard request for more information.
1. what is your platform?
("uname -a" on a Unix system)
compiler version? libc (on Linux)?
2. where did you get the sources? when?
(absolute dates are prefered over the relative ones)
3. how did you build CLISP? (what command, options &c)
please do a clean build (remove your build directory and
build CLISP with "./configure --build build" or at least
do a "make distclean" before "make")
4. if you are using pre-built binaries, the problem is likely
to be in the incompatibilities between the platform on which
the binary was built and yours;
please try compiling the sources.
5. what is the output of (lisp-implementation-version)?
6. what is the value of *features*?
7. please supply the full output (copy and paste)
of all the error messages.
If you cannot build CLISP, you can obviously skip 5 and 6,
but then you should provide more information in 1.
please see <http://clisp.cons.org/clisp.html#bugs>
for more information.
Thanks.

PS. This bug report is now marked "pending"
and will auto-close unless you respond
(in which case it will auto-re-open).

please confirm that the problem is gone in the CVS head or clisp as
downloaded from SF.

>why didn't you just remove the fastcgi.h
I didn't see it, or when I saw it in #include "fastcgi.h" I confused it
with the official/public include file for fastcgi (which also explains my
comment: "completely wrapped" -- only the official API functions are
completely wrapped). Therefore, my previous explanation was wrong: the
local fastcgi.h indeed helps with prototypes for e.g. fcgi_read_stdin.

Anyway, the current build does not use it anymore, declaring prototypes
itself via (setq ffi:*output-c-functions* t).

One may argue that this is not the examples in the impnotes which advises
to include a .h for all referenced functions. Only the .h can protect from
mismatches from subsequent changes in the declarations.
So a better fix might be:
- reinstall it, (maybe under different name, e.g. fcgiwrapper.h, never to
be confused with the public include)
- (c-lines "#include it")
- remove setq *output-c-functions*
E.g. the same state as before.

So the cause of the bug is as follows: The OP must have tried to build
clisp-2.41 from sources. fastcgi.lisp v1.9 is in 2.41 but does not have the
#include anymore, add I only added 6 days later to v1.10 the
*output-c-functions* patch.
http://clisp.cvs.sourceforge.net/clisp/clisp/modules/fastcgi/fastcgi.lisp?hideattic=0&sortby=date&view=log

My apologies for the mess caused by my confusion & actions.

Alternatives exist:
- leave it as fastcgi.h. No, that's really a bad name. On Debian I have
/usr/include/fastcgi.h. No wonder I got confused. Who's gonna guarantee
what file gets included when?
- perhaps include in it the original fastcgi includes, then one can
- use direct calls to e.g. FCGX_IsCGI() and wrappers to others e.g.
write-stdout.
See my comments at bottom of fastcgi_wrappers.c on some pros and cons of
wrappers vs. direct calls
http://clisp.cvs.sourceforge.net/clisp/clisp/modules/fastcgi/fastcgi_wrappers.c?hideattic=0&r1=1.3&r2=1.4&sortby=date
The pro argument can be considered futile given all that direct
interfacing to e.g. dynamic shared libraries.

I have removed the original comment there, namely "These [wrappers for
e.g. FCGX_IsCGI] are needed only due to the use of upper case (how
annoying)" because it did not consider the (:NAME) option to DEF-CALL-OUT.
There's no problem in interfacing to mixed case.


[Off topic] All that talk still doesn't solve the problem that
fastcgi:slurp-stdin is IMHO misdesigned. It lacks the ability to read
binary data (e.g. attachments). Any API designer volunteers?

Logged In: YES
user_id=5735

I confirm that the cvs head (unpatched) generated fastcgi.c
includes all the necessary declarations.
could this be a dupe of the problem resolved in this message?
http://article.gmane.org/gmane.lisp.clisp.general/11634/

Logged In: YES
user_id=5735

why didn't you just remove the fastcgi.h file from the
source tree?

Logged In: YES
user_id=377168

I'm sorry. A patch about "fastcgi.h" inclusion *cannot*
remove any problem associated with fcgi_read_stdin etc. for
the very simple reason that these functions do not come from
the public fastcgi API. They come from our fastcgi_wrappers.c.

I removed the inclusion of fastcgi.h last month because the
FFI module has not a single DEF-CALL-OUT to a function from
the official fastcgi.h. It solely calls our wrappers.

If fastcgi.c (which results from compilation of
fastcgi.lisp) complains, it means that it does not see the
declarations for fcgi_read_stdin etc. This should not
happen because I wrote:
(eval-when (compile)
;;NB this global affects further compilations in this session
(setq ffi:*output-c-functions* t))
which should cause declarations to be output during
compilation of fastcgi.lisp into fastcgi.c.
If this does not happen, then that's what needs to be
investigated.

In my Linux environment, this caused the following
declarations to appear in fastcgi.c:
...
object module__fastcgi__object_tab[1];
object_initdata_t module__fastcgi__object_tab_initdata[1];
uintC module__fastcgi__object_tab_size = 0;

extern char* (fcgi_getenv)();
extern char* * (fcgi_env)();
extern char* (fcgi_read_stdin)();
extern int (fcgi_write_stdout)();
extern int (fcgi_write_stderr)();
extern int (fcgi_accept_wrapper)();
extern void (fcgi_finish_wrapper)();
extern int (fcgi_is_cgi_wrapper)();

void module__fastcgi__init_function_1 (module_t* module);
...

Maybe the build process in cygwin is different?
I wrote (eval-when (compile) #) because only during
compilation will CLISP create the file fastcgi.c.

In any case, "fastcgi.h" is not the answer to a problem
involving fcgi_read_stdin.

Please investigate further the origin of the gcc error.
What's going on with fastcgi.h?

Logged In: YES
user_id=5735

Reini, the patch _uncomments_ (i.e., enables) the header
inclusion, _not_ comments it out (i.e., disables).

Logged In: YES
user_id=13755

BTW: I've needed to comment out the header inclusion for
cygwin also.
Just forgot to email it after my holidays.

Logged In: YES
user_id=171319

Yes, that fixes the problem. Thanks!

Logged In: YES
user_id=5735

does this patch fix the problem?
--- fastcgi.lisp 19 Oct 2006 04:11:32 -0400 1.10
+++ fastcgi.lisp 12 Nov 2006 21:46:36 -0500
@@ -145,7 +145,7 @@


; -------------- "C" functions
-;(c-lines "#include \"fastcgi.h\"~%"); completely wrapped
+(c-lines "#include \"fastcgi.h\"~%")
(eval-when (compile)
;;NB this global affects further compilations in this session
(setq ffi:*output-c-functions* t))

Logged In: YES
user_id=171319

Add

#include "fastcgi.h"

To top of fastcgi.c