#380 fastcgi build error
gmake[1]: Entering directory `/tmp/clisp-2.41/src/fastcgi'
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith
-Wimplicit -Wreturn-type -Wmissing-declarations
-Wno-sign-compare -O2 -fexpensive-optimizations
-falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. .. -I..
-c fastcgi.c
In file included from fastcgi.c:1:
../clisp.h:682: warning: register used for two global
register variables
fastcgi.c: In function 'module__fastcgi__init_function_2':
fastcgi.c:27: error: 'fcgi_getenv' undeclared (first
use in this function)
fastcgi.c:27: error: (Each undeclared identifier is
reported only once
fastcgi.c:27: error: for each function it appears in.)
fastcgi.c:28: error: 'fcgi_env' undeclared (first use
in this function)
fastcgi.c:29: error: 'fcgi_read_stdin' undeclared
(first use in this function)
fastcgi.c:30: error: 'fcgi_write_stdout' undeclared
(first use in this function)
fastcgi.c:31: error: 'fcgi_write_stderr' undeclared
(first use in this function)
fastcgi.c:32: error: 'fcgi_accept_wrapper' undeclared
(first use in this function)
fastcgi.c:33: error: 'fcgi_finish_wrapper' undeclared
(first use in this function)
fastcgi.c:34: error: 'fcgi_is_cgi_wrapper' undeclared
(first use in this function)
gmake[1]: *** [fastcgi.o] Error 1
Logged In: YES
user_id=171319
Add
#include "fastcgi.h"
To top of fastcgi.c
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
Yes, that fixes the problem. Thanks!
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=5735
Reini, the patch _uncomments_ (i.e., enables) the header
inclusion, _not_ comments it out (i.e., disables).
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
why didn't you just remove the fastcgi.h file from the
source tree?
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=377168
Originator: NO
>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
Originator: NO
please confirm that the problem is gone in the CVS head or clisp as downloaded from SF.
Logged In: YES
user_id=5735
Originator: NO
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).
Logged In: YES
user_id=171319
Originator: YES
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.
Logged In: YES
user_id=5735
Originator: NO
please download the source distribution from SF and not from gnu.org.
gnu.org does not allow me to replace the broken distribution.
Logged In: YES
user_id=377168
Originator: NO
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.