OS X import bug?

Manoj Plakal terabaap at yumpee.org
Fri Jan 25 00:16:29 EST 2002


Is there some OS X linker option one can give
while building the extension such that
the symbols in baz.c are exposed to
foomodule.c while building module foo,
but these baz symbols are not exposed
outside module foo? Would the
"two-level namespace" as opposed
to the flat namespace be of use here?

Manoj


Manoj Plakal wrote:

> 
> Steven,
> 
> Thanks for the patch. I applied it to the
> 2.2 tree that I had checked out from CVS
> and re-built foo and bar and tried
> importing them again.
> 
> eve(1418):test% python
> Python 2.2+ (#2, Jan 24 2002, 20:36:33)
> [GCC 2.95.2 19991024 (release)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import foo
> var_for_foo = 1
>  >>> import bar
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError: dyld: python multiple definitions of symbol _var_for_bar
> foo.so definition of _var_for_bar
> bar.so definition of _var_for_bar
> Failure linking new module
>  >>>
> 
> var_for_foo and var_for_bar are defined in baz.c which
> is included in both modules foo and bar. The modules
> were compiled with a simple distutils setup.py file
> (which I had included in my earlier post) which
> builds the two modules with -flat_namespace.
> 
> The same source code works fine on Red Hat Linux 7.2
> with Python 2.1 and Win98 with Python 2.2b2.
> 
> So my question now is: is this really a bug
> in the OS X implementation, or is this how
> Python is supposed to work (and the Linux
> and Win32 dynamic loading implementations
> just happen to allow this without errors)?
> 
> If I am to file a bug at Sourceforge, I'd
> like to know exactly what the bug is :)
> 
> Manoj
> 
> 
> Steven Majewski wrote:
> 
>>
>> Below is a patch that adds a call to NSLinkEditError, which will
>> give you a more explicit error message about what's wrong. It's
>> how I discovered which symbol was the problem with that bug:
>>
>>
>> *** dynload_next.c.0    Fri Jan 18 13:50:06 2002
>> --- dynload_next.c    Fri Jan 18 14:08:13 2002
>> ***************
>> *** 150,157 ****
>>           if (errString == NULL) {
>>               newModule = NSLinkModule(image, pathname,
>>                   
>> NSLINKMODULE_OPTION_BINDNOW|NSLINKMODULE_OPTION_RETURN_ON_ERROR);
>> !             if (!newModule)
>> !                 errString = "Failure linking new module";
>>           }
>>           if (errString != NULL) {
>>               PyErr_SetString(PyExc_ImportError, errString);
>> --- 150,164 ----
>>           if (errString == NULL) {
>>               newModule = NSLinkModule(image, pathname,
>>                   
>> NSLINKMODULE_OPTION_BINDNOW|NSLINKMODULE_OPTION_RETURN_ON_ERROR);
>> !             if (!newModule) {  // sdm7g
>> !               int errNo;
>> !               char *fileName, *moreErrorStr;
>> !               NSLinkEditErrors c;
>> !               errString = "Failure linking new module";
>> !               NSLinkEditError( &c, &errNo, &fileName, &moreErrorStr );
>> !               errString = strcat( fileName, errString );
>> !               errString = strcat( moreErrorStr, errString );
>> !             } // sdm7g
>>           }
>>           if (errString != NULL) {
>>               PyErr_SetString(PyExc_ImportError, errString);





More information about the Python-list mailing list