[Pythonmac-SIG] pyobjc.so [was: Knock me over with a spoon!]

[Bob Ippolito]

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