[Zope] (no subject)

[Jeffrey P Shell]

These are some quick notes I made today as I got back to working on  
this issue.  Getting Python on MacOS X Server to be shared-library  
friendly is still not as clear as it should be, but this is  
definitely easier than trying to build Python with the next-framework  
option (which produces some behaviors that the Zope builder scripts  
do *NOT* like).  I plan on getting this howto onto zope.org as soon  
as I do a little bit more formatting.  I also plan to submit this to  
some Mac OS X sites such as xclave.macnn.com and stepwise.com (esp.  
in hopes that Scott Anguish can get a threaded/shared-lib friendly  
Python into the Darwin base!)
--------
Building Zope 2.1.3 on MacOS X Server

Last time I told this story, I was having problems getting dynamic  
libraries (.so files) to work with Python without configuring with  
the --with-next-framework option, which didn't compile to the results  
I wanted.  Below are the steps to building Python 1.5.2 with threads  
and dynamic libraries on MacOS X Server and to building Zope 2.1.3.

Python::
First - configuring

./configure --with-threads --with-dyld

Next - MAKE

make LDFLAGS="-undefined suppress"
make install

The LDFLAGS="-undefined suppress" option is passed into the linker  
and will suppress errors about undefined references.  Without this  
setting, dynamic libraries will not get past the linker stage.  Make  
install installs Python into the configured area (you should be root  
to do this).


Zope::

A change has to be made in one of the files used for  
building/configuring Zope that will hopefully be ironed out in the  
near future.  For now, do the following

In inst/do.py, change line 135 from
   do('make')
to
   do('make LDFLAGS="-undefined suppress"')

(We'll find a way of fixing this in the future so this shouldn't  
have to be edited.  There should be a Python configuration option  
when building for setting these LDFLAGS into the default  
Makefile.pre.in)


Then, for reasons currently unknown to me, cPickle issues have to be  
resolved.  The Zope build process makes two cPickle.so files.  These  
files appear to be identical and cause a conflict with each other at  
runtime due to multiple symbol definitions, and they cause a  
conflict with the cPickle.so that is built with Python.

Lastly:
cd lib/python/
rm cPickle.so

cd lib/python/ZODB/
mv cPickle.so /usr/local/lib/python1.5/lib-dynload/

You should be root to do the last step of moving the Zope cPickle.so  
into the default Python area.


This is still too much to do, in my opinion, but it's the best way  
I've found yet.  Any suggestions about how to get the LDFLAGS option  
set at Python configuration time so that the generated Makefiles that  
Zope uses will have them set, let me know.  I tried setting LDFLAGS  
as an environment variable before running configure, but it uses  
$LDFLAGS at the beggining of configuration to test the C compilor,  
and since the '-undefined suppress' option is a linker option, an  
error is returned and configuration stops.

Or, any suggestions or advice on how to set Python up to resolve  
multiple definitions (due to multiple cPickle.so files) automatically  
will be greatly appreciated.  The cPickle in Zope is newer than the  
one in Python 1.5.2, I believe.

On my to-do list now (but pretty far down the list, sadly) is to  
make this into a MacOS X Server package similar to other Zope  
releases (meaning, the Zope package will be a full release with its  
own Python).  The timeframe of this is uncertain.

jeffrey@Digicool.com