[Pythonmac-SIG] pyobjc.so [was: Knock me over with a spoon!]
Bob Ippolito
bob@redivi.com
Sat, 19 Jan 2002 16:51:01 -0500
On Saturday, January 19, 2002, at 03:32 PM, Steven Majewski wrote:
>
>
> On Sat, 19 Jan 2002, Jack Jansen wrote:
>
>>
>> On Saturday, January 19, 2002, at 01:06 AM, Bob Ippolito wrote:
>>
>>> Do _not_ use the dynload_next that ships with python 2.2! It's
>>> broke as hell. If you have say, MyPackage/blah.so and
>>> MyOtherPackage/blah.so it will confuse the two. The version
>>> that Apple wrote works perfectly with the libdl stuff in Python.
>>
>> Bob,
>> you mentioned this earlier (or was that someone else?), but I'm
>> not sure I fully understand the problem.
>
> I also don't understand the problem, and if there was an earlier
> discussion, I must have missed it.
Okay. Let's see. I have two C modules called time.so. One is part of
the standard python distribution, and the other is in the pygame
package. Sometimes, quite often really, I would like to use them both
at the same time.
Using dynload_next, if you do:
import time
import pygame.time
python will load the first time.so, and it will create a module PyObject
for the second, but it will initialize it with the contents of the first
time.so and not try and load another dynlib. In other words,
time.__dict__ == pygame.time.__dict__, they both have the contents of
the first module loaded with the name time.so, even though they are on
different paths. If I had loaded them in reverse order, both modules
would have the contents of site-packages/pygame/time.so .. Python
reports no errors during this process.
If you turn on DYLD_PRINT_LIBRARIES (setenv DYLD_PRINT_LIBRARIES) it
will only show the first time.so
Using apple's libdl, everything works perfectly fine. It recognizes
both libraries as separate, they have separate dictionaries, and
DYLD_PRINT_LIBRARIES shows two libraries being linked.
>
>> Also, if there is a
>> problem I would prefer to fix it in the Python source rather
>> than depend on yet another external package.
>
> I've got the package (I used it for XlispStat and some other ports)
> -- it's used, I believe in Apache, but the libs are not part of
> Mac OSX, even with the development tools installed, so, unless
> we include it with Python, builds by folks who don't read the
> 'first install libdl' instruction are going to fail.
Okay, so why doesn't someone take libdl and inject it into the python
source tree? I haven't had time for this myself. I was hoping someone
would hear what I was saying and patch the original or just throw libdl
into python.
I'm expecting that libdl will be included in later releases of the
developers toolkit and/or OS X itself, I don't see why apple would write
it and leave it out.w
>
>> Moreover, I think
>> the dynload_next magic may be needed for the ObjC stuff (Steve?).
>
> pyobjc is a normal python extension so loading it is not dependent
> (I believe) on a particular type of dynamic loading. Once pyobjc
> is loaded, it uses the NSBundle and NSUnarchiver routines to load
> other obj-c extensions like AppKit.
>
> If I can figure out how to disable dynload and enable libdl,
> I'll give it a try and see if it still works. Do you know if
> this makes any difference for how the shared modules are built ?
> (I wouldn't think so, but...)
>
It's all in python's configure script, it's only a couple lines you need
to change. Python already detects the presence of libdl on systems that
have it installed, it just ignores it entirely when it goes to choose
the dynamic loader because it thinks dynload_next is a better fit.
There is no difference in the way that shared modules are built either
way, only that when you load them, they work as expected with libdl :)
-bob