[C++-sig] Building boost.python on Mac OS X
Ralf W. Grosse-Kunstleve
rwgk at yahoo.com
Sat Sep 13 03:36:29 CEST 2003
--- Jonathan Brandmeyer <jbrandmeyer at earthlink.net> wrote:
> > > 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?
Done. (I didn't realize that Python's configure picks up gcc instead of cc if
gcc is first on PATH.)
> 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.
Wow! That's very interesting.
Did you try using /usr/bin/python?
Now I am beginning to wonder if it is better to work with a framework or a
non-framework build. I am not an Apple user. Could someone more experienced
with OS X name some pros and cons?
> 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...
Thanks for sharing this information!
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
More information about the Cplusplus-sig