Re: fastcgi under bsdi?

Gary Shea (shea@xmission.com)
Fri, 15 Nov 1996 14:47:01 -0700 

Message-Id: <199611152149.OAA24739@mail.xmission.com>
Date: Fri, 15 Nov 1996 14:47:01 -0700
To: darren@aeonics.com (Darren Reinig)
From: shea@xmission.com (Gary Shea)
Subject: Re: fastcgi under bsdi?

This is getting a bit off fastcgi, but just so bsdi users
can hear it all... I'm not connected to bsdi but I have been 
working with the system a lot recently.  It has its problems,
but I'm starting to kind of like it :)

>> I recommend using GCC.  I compiled it using gcc with 0 problems.  

Cool.

>> Although you may have a Perl problem as well (we have only been doing 
>> FastCGI in C).

You WILL have perl problems with the default fastcgi files and
the perl hints file for bsdi.  See below.

>> We were unable to get a clean compile for Perl 5.003 
>> using sh**cc2, however...  

This is NOT TRUE under BSDI 2.1.  I have built perl5.003 a dozen
times under bsdi 2.1 with shlicc2.  It has built cleanly and passed
100% of the perl test suite.  I am running thousands of lines
of perl code on 10 different machines through the resulting perl
executables.

In some bizarre situations, like building fastcgi,
the perl5.003 hints file for bsdi has a problem 
(my fault...) in that it specified shlicc2
as the compiler (cc=shlicc2) when shlicc2 should only be used
as the loader (at least that part is right!).

>BSDI's development enviroment is the worst I've used since I did the
>DOS thing. Neither GNU cc or binutils will compile out of the box for
>BSDI, so your stuck using the ones that come with it. In bsdi, cc is
>actually GNU cc v1.03, and gcc is actually gcc 2.4 or 5 something. The
>shlicc and shlicc2 programs are actually shell script wrappers for the
>respective compilers which somehow implement shared libraries.

Mmmm, let's be accurate here.  On BSDI 2.1:

cc is gcc 1.42
gcc is 2.7.2
You're quite right about shlicc* -- it is indeed a shell script
which calls gcc 1.42 and links bsdi's rather pitiful dynamic loading
libraries arrangement.  Its real problem is that creating new
dynamically loadable libraries is a pain.

        Gary
-----------------------------------------------------------------------
Gary Shea                                          Salt Lake City, Utah
shea@xmission.com                         http://www.xmission.com/~shea