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

[Ralf W. Grosse-Kunstleve]

To David Abrahams: question for you at the end.


--- Rene Rivera <grafik666 at redshift-software.com> wrote:
> The two things you should need to set for it to work are the location of the
> compiler and the version of python:
> 
>     bjam -sGCC_ROOT_DIRECTORY=/usr/local/gcc-3.3 -sPYTHON_VERSION=2.3 ...

I had to make a few changes to darwin-tools.jam:

Index: darwin-tools.jam
===================================================================
RCS file: /cvsroot/boost/boost/tools/build/darwin-tools.jam,v
retrieving revision 1.6
diff -r1.6 darwin-tools.jam
93,94c93,94
< flags darwin CFLAGS : -Wno-long-double -no-cpp-precomp ;
< flags darwin C++FLAGS : -fcoalesce-templates ;
---
> #flags darwin CFLAGS : -Wno-long-double -no-cpp-precomp ;
> #flags darwin C++FLAGS : -fcoalesce-templates ;
187c187
<     $(.GCC_BIN_DIR)$(.GXX) -c -Wall -ftemplate-depth-100 -U$(UNDEFS)
-D$(DEFINES) $(CFLAGS) $(C++FLAGS) -I"$(HDRS)" -I"$(STDHDRS)" -o "$(<)" "$(>)"
---
>     $(.GCC_BIN_DIR)$(.GXX) -c -w -ftemplate-depth-120 -U$(UNDEFS)
-D$(DEFINES) $(CFLAGS) $(C++FLAGS) -I"$(HDRS)" -I"$(STDHDRS)" -o "$(<)" "$(>)"

The standard gcc 3.3 (as opposed to Apple's c++) does not support
-no-cpp-precomp and -fcoalesce-templates (results in errors).
-Wno-long-double is also not supported by gcc 3.3 (?).
-Wall generates an overwhelming amount of noise. For now let's use
-w until everything else is sorted out.

My command:

cd boost/libs/python/test
bjam -sGCC_ROOT_DIRECTORY=/usr/local_cci/gcc-3.3 -sPYTHON_VERSION=2.3
-sTOOLS=darwin -sBUILD=debug -sALL_LOCATE_TARGET=/net_coral/scratch1/rwgk/bjam
-sRUN_ALL_TESTS=1 -d+2 test

The full output is here:

http://cci.lbl.gov/~rwgk/tmp/bjam_mac_os_10_2003_05_24_0700.log

Remarks:

This sequence of commands issued by bjam has no effect and should be omitted:

   
DYLD_LIBRARY_PATH=/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config

    export DYLD_LIBRARY_PATH 

The options

    -Wl,-dylib_compatibility_version,1.31.0 -W,l-dylib_current_version,1.31.0

while linking libboost_python.dylib should be omitted unless we
establish a real versioning system (too much work for very little
benefit in my mind).

The rule for linking the embedding example does not work:

    /usr/local_cci/gcc-3.3/bin/g++  -g  -o
"/net_coral/scratch1/rwgk/bjam/libs/python/test/bin/embedding.test/darwin/debug/runtime-link-dynamic/embedding"

"/net_coral/scratch1/rwgk/bjam/libs/python/test/bin/embedding.test/darwin/debug/runtime-link-dynamic/embedding.o"
 \
     
-L"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config"
-L"/net_coral/scratch1/rwgk/bjam/libs/python/build/bin/libboost_python.dylib/darwin/debug/runtime-link-dynamic/shared-linkable-true"
    -lpython2.3 -ldl -lutil -lboost_python  \
      -framework /Library/Frameworks/Python.framework/Versions/2.3/Python   

/usr/bin/ld: can't locate file for: -lpython2.3

I am not sure what to do here because I am not familiar with embedding,
but I think
-L"/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/config"
has no effect and should be omitted everywhere.

These messages

/usr/bin/ld: Undefined symbols:
boost::python::converter::detail::registered_base<int volatile
const&>::converte
rs

can most likely be resolved by adding class_<dummy>(...) statements to
the source code. E.g.:

#if defined(__APPLE__) && defined(__MACH__) \
 && defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 3 &&
__GNU_PATCHLEVEL__ == 0
    class_<dummy>("_dummy", no_init);
#endif

David, OK to do this?

Note that there are no internal compiler errors while compiling the
regression tests. Pure luck!

Ralf


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com