[C++-sig] Re: Mac OS 10 success

Ralf W. Grosse-Kunstleve rwgk at yahoo.com
Fri May 23 20:40:00 CEST 2003

--- Rene Rivera <grafik666 at redshift-software.com> wrote:
> These are the bjam equivalents with the current state of darwin-tools.jam...
> ### currently called as "c++" not "g++"
> >g++

Apple's current c++ (based on gcc 3.1) doesn't work. I am using g++ 3.3
compiled from sources. How about renaming the toolset to darwin-gcc-tools.jam?

>     ### <shared-linkable>true (on for DLL and PYD targets)
> >   -fPIC
>     ### currently set to -ftemplate-depth-120
> >   -ftemplate-depth-120
>     ### currently set to -Wall ?
> >   -w

-Wall creates a lot of noise for my compilations, but we could still try it for
the Boost.Python regression tests.

>     ### <optimization>off
> >   -O0
>     ### <inlining>off
> >   -fno-inline
>     ### I presume these are set by the libboost_python target?

The -DBOOST_PYTHON_MAX_BASES=2 is an attempt to cut down our compile-times. I
think it should be omitted from the bjam toolset. The -DBOOST_PYTHON_SOURCE is
already set somewhere by bjam (?).

>     ### <include>$BOOST_ROOT
> >   -I/net/cci/rwgk/boost_releases/1_30_0/mac/boost
>     ### <include>/Library/Frameworks... (It seems that python.jam would need
> to change to look here when the correspoding PYTHON_VERSION is set. That is
> setting the PYTHON_ROOT to
> "/Library/Frameworks/Python.framework/Versions/$(PYTHON_VERSION)" )

I obtain the -I path by looking at sys.executable and sys.version in Python.
I am not sure how this could fit into the bjam framework.

> >   -I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3
> >   -c
> >   -o boost/libs/python/src/tuple.os
> >   /net/cci/rwgk/boost_releases/1_30_0/mac/boost/libs/python/src/tuple.cpp
> >Linking libboost_python.dylib (three commands):
>     ### I'm fairly sure there are additional library path seetings here?

Sorry, I don't understand what you mean here.

>     ### Yea, that's just what the DLL target does, except for...
> >ld -dynamic -m -r -d -o libboost_python.lo boost/libs/python/src/numeric.os
> >boost/libs/python/src/list.os boost/libs/python/src/long.os
> >boost/libs/python/src/object_operators.os
> >
> >g++ -nostartfiles -Wl,-dylib -ldylib1.o
>     ### <framework>/Library/Frameworks/... (this is currently put in as
> <framework>Python, is that enough? Or is the complete path-spec needed?)

I am not entirely sure I understand your question. Trial answer: I only could
get it to work when specifying the full path. My experiments with
-L/Library/Frameworks/.../2.3 failed. Maybe because Python doesn't exist with a
.dylib extension?

> >   -framework /Library/Frameworks/Python.framework/Versions/2.3/Python
> >-o libtbx/libboost_python.dylib libboost_python.lo
> >
> >rm -f libboost_python.lo
> >
> >Compiling an extension module:
>     ### Same as the previous comments.
> >g++ -fPIC -ftemplate-depth-120 -w -O0 -fno-inline
> >-Ilibtbx/include -I/net/cci/rwgk/boost_releases/1_30_0/mac/libtbx/include
> >-I/net/cci/rwgk/boost_releases/1_30_0/mac/scitbx/include
> >-I/net/cci/rwgk/boost_releases/1_30_0/mac/boost
> >-I/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3 -c -o
> >scitbx/fftpack/boost_python/fftpack_ext.os
> >
> >Linking an extension module:
> >
> >g++ -w
>     ### I thought -bundle didn't take a value? (Currently only -bundle is
> added)

> > -bundle /Library/Frameworks/Python.framework/Versions/2.3/Python

You are right, -bundle doesn't take a value. But the full
/Library/.../2.3/Python path has to appear somewhere. Maybe this is most

g++ -w -bundle -bundle_loader
Python -o libtbx/scitbx_boost/rational_ext.so
s -Llibtbx -L/net/cci/rwgk/boost_releases/1_30_0/mac/libtbx
n -lboost_python /Library/Frameworks/Python.framework/Versions/2.3/Python -lm

>     ### <bundle-loader>... (Currently this is added by python.jam as
> <bundle-loader>$(PYTHON_ROOT)/bin/python$(PYTHON_VERSION) when building PYD
> targets)

This didn't work for me with the Python 2.3b1 installation.

> >-bundle_loader /Library/Frameworks/Python.framework/Versions/2.3/Python -o
> >libtbx/scitbx_boost/fftpack_ext.so
> scitbx/fftpack/boost_python/fftpack_ext.os
> >-Llibtbx -L/net/cci/rwgk/boost_releases/1_30_0/mac/libtbx
> -lscitbx_boost_python
> >-lboost_python -lm
> So as far as I can see the only changes needed are in python.jam, and
> possibly the "-bundle" option in the toolset.

If you modify the toolset and check it in I will try it out. I don't think
there is a reason to be conservative since the old one never worked for
compiling and linking all Boost.Python regression tests AFAIK, due to bugs and
limitations of compilers older than gcc 3.3.


Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.

More information about the Cplusplus-sig mailing list