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

[Steven Majewski]

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.

> 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.

> 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...)

> Could you explain the problem, and why it is fixed if you use
> the libdl version?

Ditto.

You said that dynload_next is broken -- so I assume the other
solution is just to write a new dynload_darwin that does it
the right way, rather than to depend on the dlopen emulation
being installed. (i.e. I think you're saying this is a problem
with dynload_next's implementation and not the darwin dynload
libs themself. )

The other option would be to make configure make using the
emulation libs the default if they are installed, otherwise,
fall back on the current method.

-- Steve Majewski