#380 fastcgi build error

build problems
closed-works-for-me
Sam Steingold
clisp (525)
5
2006-11-16
2006-11-12
Matthew Kennedy
No

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

Discussion

  • Logged In: YES
    user_id=171319

    Add

    #include "fastcgi.h"

    To top of fastcgi.c

     
  • Sam Steingold
    Sam Steingold
    2006-11-13

    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!

     
  • Reini Urban
    Reini Urban
    2006-11-13

    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.

     
  • Sam Steingold
    Sam Steingold
    2006-11-13

    Logged In: YES
    user_id=5735

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

     
  • Jörg Höhle
    Jörg Höhle
    2006-11-13

    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?

     
  • Sam Steingold
    Sam Steingold
    2006-11-13

    Logged In: YES
    user_id=5735

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

     
  • Sam Steingold
    Sam Steingold
    2006-11-13

    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/

     
  • Jörg Höhle
    Jörg Höhle
    2006-11-15

    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?

     
  • Sam Steingold
    Sam Steingold
    2006-11-15

    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.

     
  • Sam Steingold
    Sam Steingold
    2006-11-15

    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).

     
  • Sam Steingold
    Sam Steingold
    2006-11-15

    • status: open --> pending-works-for-me
     
  • 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.

     
    • status: pending-works-for-me --> open-works-for-me
     
  • Sam Steingold
    Sam Steingold
    2006-11-16

    • labels: --> clisp
    • assigned_to: nobody --> sds
    • status: open-works-for-me --> closed-works-for-me
     
  • Sam Steingold
    Sam Steingold
    2006-11-16

    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.

     
  • Jörg Höhle
    Jörg Höhle
    2006-11-17

    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.