[Fwd: Re: [Pythonmac-SIG] OS X import bug?]

[Steven Majewski]

On Sat, 26 Jan 2002, Jack Jansen wrote:

> My feeling is that the problem is with dynload_next.c, which is
> a very old file that hasn't seen any development for many years
> (between NeXT's near-demise and OSX's appearance). The problem
> is exacerbated by the fact that the APIs used in dynload_next.c
> or very poorly documented, if at all. My guess (can anyone
> confirm this or point me to more info?) is that the
> NSIsSymbolNameDefined() call at the beginning is incorrect, and
> will return the wrong module upon import of a second module with
> the same name.

Yes. I think a first start would be to strip out all of the
code that's unused for OSX, maybe renaming it dynload_darwin,
and add the extra error checking I posted earlier.

[ BTW: I retract that earlier comment about libdl not working --
  although it looked from configure that it was buildidng with
  libdl, the result of the build seems to have still used
  dynload_next. ]


> Maybe someone who is experiencing the problem can comment out
> that quick-return section and see whether dynload_next.c then
> works as expected? Or will we then immedeately run into flat
> namespace problems (two routines called initfoo)?

I did a quick rebuild, and what happens with that return commented
out is that I now get a duplicate symbol error on trying to import
both timemodule.so and mypackage/timemodule.so : two inittime's.

Maybe I'll try one of the other suggestions along with that and
see what happens.

-- Steve