>> Well, after wasting the better part of a day tracking down a computer
>> capable of running 10.2, installing 10.2 on it, getting the latest
>> updates and the newest 10.2 developer tools, I find that neither
>> python 2.5 from svn (today's snapshot or a checkout from the 8th)
>> *NOR* the svn sn
On 10-mrt-2006, at 23:25, Zachary Pincus wrote:
>> If you come up with a patch for (2) against Python's svn trunk that
>> is tested and works on 10.2 then I'll commit it. It's not
>> appropriate to make this sort of change against Python 2.4,
>> though. *Maybe* for the universal branch that Ron
> If you come up with a patch for (2) against Python's svn trunk that
> is tested and works on 10.2 then I'll commit it. It's not
> appropriate to make this sort of change against Python 2.4,
> though. *Maybe* for the universal branch that Ronald and I are
> doing, because that's also unl
On 6-mrt-2006, at 3:24, Bob Ippolito wrote:
>
> On Mar 5, 2006, at 5:56 PM, Zachary Pincus wrote:
>
>> Otherwise, Mac Python's bundle loading code should have a way to
>> expose the global symbol loading mechanism (necessary for C++ RTTI
>> with templates) to user code. There are two ways that I
>> I think the Mac OS X box on the sourceforge compile farm may be 10.2.
Only if you're a developer on some SF project. Is there a python
project someone can add me to so I can test this (and the dl module)
patch? Or should I register some dummy project?
Zach
Thanks for your feedback, Bob.
>> I don't have access to a 10.2 machine currently, so if someone is
>> able to test this patch on 10.1, 10.2, and/or 10.3, I would be
>> most grateful. I can try to find some 10.2 install disks (and hope
>> that my computer can run 10.2) if nobody has easy acc
On Mar 6, 2006, at 12:20 AM, Zachary Pincus wrote:
>>> (2) Move to using dlopen() to load the libraries instead of
>>> NSLinkImage. This might need some minor changes to
>>> dynload_shlib.c, and it would need the configure script to be
>>> smart enough to choose dynload_next.c on 10.2 and b
>> (2) Move to using dlopen() to load the libraries instead of
>> NSLinkImage. This might need some minor changes to
>> dynload_shlib.c, and it would need the configure script to be
>> smart enough to choose dynload_next.c on 10.2 and below.
>
> If you come up with a patch for (2) against Pyt
On Mar 5, 2006, at 5:56 PM, Zachary Pincus wrote:
> Otherwise, Mac Python's bundle loading code should have a way to
> expose the global symbol loading mechanism (necessary for C++ RTTI
> with templates) to user code. There are two ways that I imagine
> this could be added:
>
> (1) Provide
Thanks again Bob for the feedback.
> MH_BUNDLE is not MH_DYLIB and neither are ELF. Everything you
> think you know about shared libraries isn't quite the same on Mac
> OS X. I suggest you read up on Mach-O, I don't really have time to
> answer all of your questions about it.
My admittedl
On Mar 5, 2006, at 4:16 PM, Zachary Pincus wrote:
> Thanks for the information, Bob. I appreciate your help.
>
>> Actually it's because Python extensions are bundles. Bundles are
>> NOT shared libraries and can not do what you want. Additionally,
>> Python on Mac OS X doesn't use dl to load its
Thanks for the information, Bob. I appreciate your help.
> Actually it's because Python extensions are bundles. Bundles are
> NOT shared libraries and can not do what you want. Additionally,
> Python on Mac OS X doesn't use dl to load its extensions, it uses
> lower-level means... so the R
On Mar 5, 2006, at 12:32 PM, Zachary Pincus wrote:
>>> [need to share symbols across dso boundaries snipped]
>>> Any help or suggestions or thoughts would be greatly appreciated,
>>
>> Don't do that?
>>
>> Python uses two-level namespaces on OSX, and for a purpose: to avoid
>> accidentally pickin
>> [need to share symbols across dso boundaries snipped]
>> Any help or suggestions or thoughts would be greatly appreciated,
>
> Don't do that?
>
> Python uses two-level namespaces on OSX, and for a purpose: to avoid
> accidentally picking up a symbol from another extension. IIRC You
> should
>
On 5-mrt-2006, at 8:46, Zachary Pincus wrote:
> Hi folks,
>
>
> Any help or suggestions or thoughts would be greatly appreciated,
Don't do that?
Python uses two-level namespaces on OSX, and for a purpose: to avoid
accidentally picking up a symbol from another extension. IIRC You should
build a
Hi folks,
I have a tricky issue with some python extension modules that need to
share symbols between themselves.
The setup: I am creating python modules to wrap a large template-
based C++ image processing library. The fundamental class that each
of these modules needs to be able to create,
16 matches
Mail list logo
