crummy build process for FastCGI-integrated Perl

Mark Brown (
Tue, 18 Jun 1996 10:19:33 -0400

Message-Id: <>
Subject: crummy build process for FastCGI-integrated Perl
Date: Tue, 18 Jun 1996 10:19:33 -0400
From: Mark Brown <>

Nigel Metheringham observes:

    Also I am *very* unhappy about the perl build process - making a new 
    perl for fastcgi is a real bitch!  Particularly as your build process 
    did not work on our Sun (SunOS 4.1.3 patches) system so I had to do a 
    lot of hacking around, then to find that the extra cflags broke the 
    Configure test programs, so other things didn't work (ie no signal 
    names!).  I eventually configured as normal (no fastcgi changes), 
    then edited (at the prompt) and added the cflags, ldflags & 
    libs entries, and changed the stdio settigs (std stdio and base etc 
    entries - all together in to undef.  This worked and 
    tested OK.

I can assure you that we suffered comparable pain getting it to
build on four platforms.

    Would it not be possible to:-
      1. Just have an FCGI module, leaving the main perl stdio alone.
      2. Have a modified CGI module which uses the FCGI input routines.
      3. State that all output must go via a different file descriptor
         which is handled by FCGI.  You could then attach STDOUT to that 
         descriptor at the top of the program if you wished.

    Building a new perl with non-standard build process is a pain, and I 
    have to admit I have installed it under a different name since I 
    don't really trust it :-)

Your suggestions are entirely reasonable.

I have spent some time puzzling over the Perl documentation,
trying to figure out how to provide my own implementation
of the filehandle type, but haven't made much progress.  I'm
quite willing to collaborate with a perlguts expert on doing
the FastCGI-Perl integration right, but I don't think I have
time to become a perlguts expert on my own.