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