[Zope] Compiling on BSDI 3.0; using Zope on iServer.com

Phillip J. Eby pje@telecommunity.com
Wed, 02 Jun 1999 09:40:17 -0500


FWIW, I successfully built Python 1.5.2 and Zope 1.10.2 (w/PCGI) on a BSDI
3 system yesterday.  I had to change Python's config.h to remove the
HAVE_DYLD and to undefine WITH_THREADS, change LDSHSARED to 'ld -r', and
generally avoid using shared objects except for Zope's C modules.  Once I
had a python that passed "make test", Zope built "out of the box" with no
changes.  I only had to make a hardlink from the cgi-bin directory to the
generated Zope.cgi, and it ran beautifully the first time.

Also for what it's worth, the box I built it on was a Verio (iServer.com)
Virtual Server B ($95/month), but a Virtual Server A ($55/month) would
probably work as well, since it's the same platform AFAIK.  Some of the
iServer engineers are now checking out Python and Zope for possible
addition to their menu of "unsupported" products that you can install on
your account automatically.  If this works out well, it should be easier to
get Zope on track for becoming an offering on Verio's lower-end virtual
hosting products, among other things.


At 09:56 AM 6/2/99 -0400, Brian Lloyd wrote:
>> 
>> gcc -D_HAVE_BSDI   -I../Components/ExtensionClass -g -O2 
>> -I/usr/local/include/python1.5 -I/usr/local/include/python1.5 
>> -DHAVE_CONFIG_H
>>  -c ./../Components/ExtensionClass/ExtensionClass.c
>> ld  ExtensionClass.o  -o ExtensionClass.so
>> ld: warning: cannot find entry symbol _start; defaulting to 08048074
>> 
>> After this point, I got a whole lot of undefined references.
>> 
>> The particular ld from Solaris 2.6 is the one supplied while 
>> the ld that
>> gives the warning prints the following with "ld -v" :-
>> 
>> GNU ld version 2.8.1 (with BFD 2.8.1)
>> 
>
>I've never tried BSDI 4, but here are some things I remember
>doing once to get it compiled on BSDI 3.x box:
>
>o add -rdynamic to LDSHARED in all of the Makefiles
>o run make -k and ignore any error messages
>o I also seem to remember that this produced extensions
>  as .o files, which I then had to rename to .so...
>