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

[Bob Ippolito]

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 
>> build?
>> (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:
--snip--
> 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 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 
respect them.

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.

-bob