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

[David Abrahams]

"Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:

> For the records:
>
> Based on the work done earlier by Rene Rivera and Nick Sauter I've been
> able to successfully port all our Boost.Python bindings to Mac OS
> 10.2.

Cool!

> I am using:
>
>   - Python 2.3b1 as a "framework installation"
>   - gcc 3.3 compiled from sources
>   - Boost 1.30.0 with a few small patches
>
> The Boost patches are attached. Strictly speaking it is probably
> "wrong" to simply disable the static assertions in
> type_with_alignment.hpp, but all our regression tests pass anyway.

Hmm, those things assert that:

    BOOST_STATIC_ASSERT(found >= Align);

The alignment of the result type is at least as great as the alignment sought.

    BOOST_STATIC_ASSERT(found % Align == 0);

The alignment of the result type is a multiple of the alignment
sought.

If it's failing, it means either that our ability to calculate
alignments is completely messed up or that we're allocating data at
an inappropriate alignment.  I guess the latter isn't so bad, as long
as it doesn't crash, but I'd like to know which it is.

Can you describe the case where it's failing?  An instantiation
backtrace might be quite illuminating.

> The patch for as_to_python_function.hpp disables another static
> assertion that is probably not critical. 

It's critical for users.

> The patch for wrap_python.hpp is for Python 2.3 compatibility.
>
> Python 2.3b1 was installed with the commands:
>   ./configure --enable-framework
>   make
>   make frameworkinstall
>
> gcc 3.3 was installed with the commands:
>   ./configure --prefix=/usr/local/gcc-3.3 --enable-languages=c,c++
>   make bootstrap
>   make
>   make install
>
> This installation does not interfere with the compiler provided
> by Apple. We source the following script before compiling:
>
> set path=(/usr/local/gcc-3.3/bin $path)
> set addl_libpath=/usr/local/gcc-3.3/lib:/usr/local/gcc-3.3/lib/soft-float
> if ( $?DYLD_LIBRARY_PATH ) then
>   setenv DYLD_LIBRARY_PATH "$addl_libpath:${DYLD_LIBRARY_PATH}"
> else
>   setenv DYLD_LIBRARY_PATH "$addl_libpath"
> endif
> unset addl_libpath
>
> Initially g++ stopped with an Internal Compiler Error while compiling
> some of our Boost.Python bindings. A workaround is to first preprocess
> the sources using the -E compiler option and redirecting the output to
> a new file. Then compile the preprocessed file. 

Oh, there's no excuse for a bug like that!

> In my case this worked for everything except one file; fortunately
> that one file compiles the normal way. Phew.  Here is my little
> script that does the trick:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/libtbx/libtbx/command_line/mac_os_x_cpp.py?rev=1.1&content-type=text/vnd.viewcvs-markup
> Instead of "g++" specify the name of the script; arguments are what
> you would normally pass to g++ for compiling.

Yikes.  I suppose we might have to build that into Boost.Build.  I
suppose instead you could call this script g++ and put it earlier in
your PATH.

> Linking libboost_python.dylib is a two-step process. Here is how
> I do it:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/libtbx/libtbx/command_line/mac_os_x_ld_bpl_dll.csh?rev=1.1&content-type=text/vnd.viewcvs-markup
>
> Linking extension modules is less complicated:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/libtbx/libtbx/command_line/mac_os_x_ld_pyd.csh?rev=1.1&content-type=text/vnd.viewcvs-markup

This appears to refer to a removed file (?)

> The last problem I had to deal with was unresolved symbols while
> linking certain extension modules (only 3 out of 29). It turned
> out that these were the only modules that did not make use of
> boost::python::class_. To fix the unresolved symbol errors I
> added a dummy class_ instance, e.g.:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/sgtbx/boost_python/row_echelon.cpp?rev=1.3&content-type=text/vnd.viewcvs-markup
> Look for "dummy"

Aww, that's awful, too.

> That's it. Easy!

You forgot the smiley.

> Well, while writing this I am running a compilation with -O3 instead of
> -O0 and evidently the Internal Compiler Errors creep up in different
> places. But at least it works with -O0.

You forgot the smiley again.

I don't like the first two patches, which aren't conditional on your
platform.  If you could make that change I wouldn't mind you checking
them in.

Would you like to write up an HTML or Wiki page on what it takes to
get this to work?  We currently have a FAQ answer which says "OSX?
nope!"

> Index: boost/python/converter/as_to_python_function.hpp
> ===================================================================
> RCS file:
> /net/cci/cvs/boost_1_30_0_cci/boost/python/converter/as_to_python_function.hpp,v
> retrieving revision 1.1.1.1
> retrieving revision 1.2
> diff -r1.1.1.1 -r1.2
> 27a28
>> #if !(defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 3)
> 31a33
>> #endif
> Index: boost/python/detail/wrap_python.hpp
> ===================================================================
> RCS file: /net/cci/cvs/boost_1_30_0_cci/boost/python/detail/wrap_python.hpp,v
> retrieving revision 1.1.1.1
> retrieving revision 1.2
> diff -r1.1.1.1 -r1.2
> 160a161,164
>> 
>> #if defined(PY_LONG_LONG) && !defined(LONG_LONG)
>> #define LONG_LONG PY_LONG_LONG
>> #endif
> Index: boost/type_traits/type_with_alignment.hpp
> ===================================================================
> RCS file:
> /net/cci/cvs/boost_1_30_0_cci/boost/type_traits/type_with_alignment.hpp,v
> retrieving revision 1.1.1.1
> retrieving revision 1.2
> diff -r1.1.1.1 -r1.2
> 108a109,110
>> #if !(defined(__APPLE__) && defined(__MACH__) \
>>  && defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 3)
> 110a113
>> #endif
>
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com