Boost.Python compiles & links on Darwin
This should be of interest to people waiting to use Boost.Python on the Macintosh. I have achieved partial success running Boost.Python modules on Darwin. The build system is based on the scheme proposed by Rene Rivera last November, with the Boost.Python library dynamically linked as a dylib, and the user's module as a bundle. Python itself must be installed as a Darwin Framework. It was also necessary to download gcc 3.2.2 from FSF rather than use the pre-installed compiler from Apple. Details are posted in the "darwin_notes" link presented on my Multi-platform build page: http://cci.lbl.gov/boost As noted, this is only a partial port. For one thing, the gcc 3.2.2 compiler doesn't seem to properly handle any C++ exceptions, so many of the modules in the Boost.Python test suite will fail. It may be necessary to wait for a proper gcc 3.3 release to fix this. Also, some work will be needed on the Boost.Python library itself to fix some compile-time problems reported in the log files (see build page). -- Nicholas K. Sauter, Ph.D. Lawrence Berkeley National Lab 1 Cyclotron Road, Bldg 4R0230 Berkeley, CA 94720-8235 nksauter@lbl.gov Voice: 510-486-5713 Fax: 510-486-5909
"Nicholas K. Sauter" <nksauter@lbl.gov> writes:
This should be of interest to people waiting to use Boost.Python on the Macintosh. I have achieved partial success running Boost.Python modules on Darwin.
This is fantastic news, Nick!
The build system is based on the scheme proposed by Rene Rivera last November, with the Boost.Python library dynamically linked as a dylib, and the user's module as a bundle. Python itself must be installed as a Darwin Framework. It was also necessary to download gcc 3.2.2 from FSF rather than use the pre-installed compiler from Apple.
Heh. I wonder if Apple has fixed the EH bugs you mention below in their local branch of GCC, and they just haven't been rolled back into the FSF version yet?
Details are posted in the "darwin_notes" link presented on my Multi-platform build page:
As noted, this is only a partial port. For one thing, the gcc 3.2.2 compiler doesn't seem to properly handle any C++ exceptions,
Is that just on the Apple platform, or everywhere? Have you reported these bugs to GNU through their GNATs system?
so many of the modules in the Boost.Python test suite will fail. It may be necessary to wait for a proper gcc 3.3 release to fix this. Also, some work will be needed on the Boost.Python library itself to fix some compile-time problems reported in the log files (see build page).
I don't see any compile-errors there that aren't supposed to happen. Link errors are another matter. The introduction of Python's bool type has changed the output of some of the runtime tests and the docstrings need to be updated. BTW, Nick, I never look at the build page; there's so much output that it's almost impossible to find errors. I don't know if it's useful to you, but I think you might run bjam with bjam -d0 all for that page so that the tests don't run. The test page can hold the test run output. Just a suggestion. Thanks for all your work on this! -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Thursday, February 27, 2003, at 08:20 AM, David Abrahams wrote:
"Nicholas K. Sauter" <nksauter@lbl.gov> writes:
The build system is based on the scheme proposed by Rene Rivera last November, with the Boost.Python library dynamically linked as a dylib, and the user's module as a bundle. Python itself must be installed as a Darwin Framework. It was also necessary to download gcc 3.2.2 from FSF rather than use the pre-installed compiler from Apple.
Heh. I wonder if Apple has fixed the EH bugs you mention below in their local branch of GCC, and they just haven't been rolled back into the FSF version yet?
Here is a link to a note by Stan Shebs (shebs@apple.com) http://gcc.gnu.org/ml/gcc/2001-10/msg00585.html which explains the state of affairs on OSX. (Assuming the info is still valid for the current gcc Apple is using, of course.) Cheers, Harri Hakula
David Abrahams wrote:
Details are posted in the "darwin_notes" link presented on my Multi-platform build page: http://cci.lbl.gov/boost
BTW, Nick, I never look at the build page; there's so much output that it's almost impossible to find errors. I don't know if it's useful to you, but I think you might run bjam with bjam -d0 all for that page so that the tests don't run. The test page can hold the test run output. Just a suggestion.
The build procedure has been updated as follows: "build" uses -d0 all "test" uses -sRUN_ALL_TESTS=1 -d0 test The web page presentation has also been cleaned up a bit. -- Nicholas K. Sauter, Ph.D. Lawrence Berkeley National Lab 1 Cyclotron Road, Bldg 4R0230 Berkeley, CA 94720-8235 nksauter@lbl.gov Voice: 510-486-5713 Fax: 510-486-5909
"Nicholas K. Sauter" <nksauter@lbl.gov> writes:
David Abrahams wrote:
Details are posted in the "darwin_notes" link presented on my Multi-platform build page: http://cci.lbl.gov/boost
BTW, Nick, I never look at the build page; there's so much output that it's almost impossible to find errors. I don't know if it's useful to you, but I think you might run bjam with bjam -d0 all for that page so that the tests don't run. The test page can hold the test run output. Just a suggestion.
The build procedure has been updated as follows:
"build" uses -d0 all "test" uses -sRUN_ALL_TESTS=1 -d0 test
The web page presentation has also been cleaned up a bit.
Thanks, that's nice! -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
David Abrahams -
Harri Hakula -
Nicholas K. Sauter