[C++-sig] Building boost.python on Mac OS X
jbrandmeyer at earthlink.net
Sat Sep 13 01:39:25 CEST 2003
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:
> Pursuing his ideas eventually lead to success. See also the other postings with
> the same subject:
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:
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
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...
More information about the Cplusplus-sig