Ok basic example as stated here:
makes the server spit out these again:
[Fri Sep 07 17:49:51 2007] [error] [client 192.168.1.4] Premature end of script headers: printenv.pl
if I place the same script outside of the fcgid folder it works fine.
I'm now going to try more complicated examples. If they fail aswel (as I presume they will)
Try to get you a debug dump... not sure when though busy weekend and then first week of school.
I got it to compile via the included projected manually adding aditional depedancys on libhttp, libapr-1 and libaprutil-1 did the trick.
Now I need to find out how it is suposed to work adn see if it works or not--
On 9/7/07, William A. Rowe, Jr. <firstname.lastname@example.org > wrote:Jorge Schrauwen wrote:
> Hmmz still getting link errors :(
> S:\source\x86\modules\mod_fcgid.2.1>apxs -llibhttpd -llibapr-1
> -llibaprutil-1 -c -i -a mod_fcgid.c
> cl /nologo /MD /W3 /O2 /D WIN32 /D _WINDOWS /D NDEBUG -I"S:\httpd-
> 2.2\include" /c /Fomod_fcgid.
> lo mod_fcgid.c
> link kernel32.lib /nologo /subsystem:windows /dll /machine:I386
> /libpath:"S:\httpd-2.2\lib" /out:mod_fcgid.so libhttpd.lib libapr-1.lib
> libaprutil-1.lib mod_fcgid.lo
> Creating library mod_fcgid.lib and object mod_fcgid.exp
> mod_fcgid.lo : error LNK2001: unresolved external symbol
That's bizare - most any author would set these up as static's within their
modules since there is no reason to export them (or attempt to bind to an
exported symbol. Either way, I suspect mod_fcgid.c has more source files
than the single module source, based on these emits. (Usually it would
scream about exported symbol being imported).
While on the subject, if this depends on a libfcgid, you probably need to
bind to that lib, too.