Building Zope and Python on MacOS X Server

Created by . Last modified on 2003/08/05.

How to build Zope 2.1.x and a shared-lib Python on MacOS X Server

This document (which is obviously dated) really reflects Mac OS X Server 1.x (the pre-Darwin releases)

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.

This how-to assumes basic knowledge of building and configuring Python on Unix.

Python::

Building Python 1.5.2 is relatively easy, but getting shared library support on MacOS X Server is a bit trickier. In order to use Zope, threads are needed and shared library support is assumed by the Zope builder scripts. This is a way to build a full Python 1.5.2 on MacOS X Server with shared library support and without being compiled for use as a NeXT Framework.

First - configuring

./configure --with-threads --with-dyld --with-host=powerpc-apple-netbsd

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.

Thoughts and future...

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.

Last modified 01/29/2000 by Jeffrey P Shell