Partial success Re: [C++-sig] boost.python on OS X 10.3 (Panther)

Rene Rivera grafik.list at
Tue Nov 4 23:19:03 CET 2003

[2003-11-04] Ralf W. Grosse-Kunstleve wrote:

>--- Rene Rivera <grafik.list at> wrote:
>> Curious... All I did was take out the -bundle_loader option.
>> Could you compare that link commands to your working SCons based build?
>> (bjam -d+2 option)
>To convince myself everything is still OK I've re-run my scons-based build
>scratch against the latest CVS. Everything turns out to work just fine.
>are a few example commands:

>c++ -bundle -bundle_loader
>/Library/Frameworks/Python.framework/Versions/2.3/Python -o
>boost/libs/python/test/str.os -Llibtbx -L/net/worm/scratch1/rwgk/hot/libtbx
>-lboost_python -lm

Well.. I'll put the bundle loader option back in if it can only work with

>This is pretty much what I had a few days ago except for the addition of
>-bind_at_load. I am still using -bundle_loader as you can see. Was your
idea to
>make this obsolete by using -F while compiling extension modules? Why do
>want to eliminate the -bundle_loader switch?

The idea came from... Your quote about what the Python build itself does for
building the built in extensions. And yes the idea was to use the -framework
option instead. Unfortunately the Apple documentation is very unclear in
many places about such things :-(

What I'm thinking now is that using the "-lboost_python" only works if you
supply the loader for it explicitly. Which makes sense if one notices that
when linking the extension is prebinding the bpl, with the errors we saw
about not having the binding of a function (which the -bind_at_load
solves)... Sorry about the rambling, trying to convince myself about this

 ...OK the bundle_loader option is back. Changes are to python.jam and

-- grafik - Don't Assume Anything
-- rrivera (at) - grafik (at)
-- 102708583 (at) icq

More information about the Cplusplus-sig mailing list