[C++-sig] Building boost.python on Mac OS X

[Jonathan Brandmeyer]

On Fri, 2003-09-12 at 08:54, Ralf W. Grosse-Kunstleve wrote:
> --- Jonathan Brandmeyer <jbrandmeyer at earthlink.net> wrote:
> > I just repeated your results on our machine and have a couple of
> > comments / questions.  The source package for Python 2.3 uses build
> > rules that are incompatible with FSF GCC.  So, I built Python with the
> > Apple-distributed GCC 3.1 and Boost.Python with the FSF-distributed GCC
> > 3.3.1.
> 
> That's exactly what I did.

I meant, can you specify that requirement on your website?

> > I'm using Boost.Python 1.30.0 (with Debian patches) with G++ 3.3.1 on
> > Debian without any ICE's.  Can you elaborate?
> 
> Debian sounds like Linux. The stacksize problem is a Mac OS X issue. Also note
> that the ICE's occur only while compiling files with a fairly large number of
> Boost.Python bindings.

I had already reduced the size of individual compilation units due to
general memory usage constraints (staying under about 300 MB) on my
Linux machine, so I never saw this problem on the OSX machine.

> It is my understanding that Boost.Python requires a framework build of Python.
> Rene had a posting about this almost a year ago:
> 
>     http://mail.python.org/pipermail/c++-sig/2002-October/002397.html
> 
> Pursuing his ideas eventually lead to success. See also the other postings with
> the same subject:
> 
>     http://mail.python.org/pipermail/c++-sig/2002-October/date.html
> 
> Ralf


Thanks for these pointers.  Based on that information and your public
build logs, I was able to build and link libboost_python.dylib and our
extension module against a non-framework installation of Python2.3.  The
following make rule does the job for libboost_python.dylib:
libboost_python.dylib: $(BOOST_OBJS)
	ld -w -d -u -o libboost_python.lo $^
	g++ -w -dynamic -undefined suppress -o $@ libboost_python.lo
	rm -f libboost_python.lo

Since all of the resulting undefined symbols are in the python2.3
executable, they are resolved at module-load time.  The two-stage
linking is a mystery to me, but I did not need to force the linker flags
for the second stage.

My extension is linked with something like this rule:
# python points to the python2.3 executable
# libboost_python.dylib is assumed to be on the standard library search
# path.
myextension.so: $(MYEXTENSION_OBJS)
	g++ -w -bundle -bundle_loader $(python) -o $@ $^ -lboost_python

GCC doesn't parse "-bundle_loader" properly without an option preceding
"-bundle".  -w is quieter than -v so...

-Jonathan Brandmeyer