Partial success Re: [C++-sig] boost.python on OS X 10.3 (Panther)
bob at redivi.com
Tue Nov 4 23:21:38 CET 2003
On Nov 4, 2003, at 4:47 PM, Ralf W. Grosse-Kunstleve wrote:
> --- Rene Rivera <grafik.list at redshift-software.com> wrote:
>> Curious... All I did was take out the -bundle_loader option.
>> Could you compare that link commands to your working SCons based
>> (bjam -d+2 option)
> To convince myself everything is still OK I've re-run my scons-based
> build from
> scratch against the latest CVS. Everything turns out to work just
> fine. Here
> are a few example commands:
> This is pretty much what I had a few days ago except for the addition
> -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 you
> want to eliminate the -bundle_loader switch?
-bundle_loader is pretty worthless with a framework Python..
-bundle_loader is useful only when you want to reference symbols that
are defined in a host executable. In the case of a framework Python,
all the Python C API is in the framework and the host executable merely
just links to it. If you use -bundle_loader, your modules may be
incompatible with certain ways of embedding the Python framework. If
you link directly to the framework, you will not have these problems
(so long as your module and the host executable links to the same
Python framework, of course, but that's another story...).
-F is only useful to change the search path for frameworks, you
shouldn't really have to worry about this until Python 2.4 becomes an
issue. I expect various things to change in Python 2.4's framework
build with respect to extension modules so please don't bother throwing
these kind of "future proof" things in, because you will probably make
incorrect guesses anyway. -f is what you want to use to link to a
framework, and you want it to follow the normal search order. If you
really feel the need to override this, you should be able to do so with
environment variables (man dyld), as I believe the linker should
With regard to -bind_at_load, this is only necessary for some C++
scenarios. There's some kind of static initialization happening, and
typically dyld likes to defer this until you try and resolve something.
Apparently whatever you're doing is not compatible with that, so Bad
Things Happen. Using -bind_at_load isn't the worst thing in the world,
it just makes loading your module slower because you're telling dyld to
stop being lazy.
More information about the Cplusplus-sig