[Python-Dev] issue 9807 - a glitch in coexisting builds of different types

[Georg Brandl]

Am 02.10.2010 00:06, schrieb Barry Warsaw:

> Let's say I build the foo module, which has an _foo extension for both the
> 3.2m and 3.2dmu builds.  Everything gets installed correctly, and you'll see:
> 
>     lib/python3.2/site-packages/foo-...egg/_foo.cpython-32m.so
>     lib/python3.2/site-packages/foo-...egg/_foo.cpython-32dmu.so
> 
> If you now run bin/python3.2dmu and try to import _foo, the right thing
> happens (foreshadowing) assuming that the directory listing for the foo.egg is
> alphabetical.
> 
> But what happens if you run bin/python3.2m and import _foo?  Yeah, well, even
> though there's a _foo.cpython-32m.so sitting right there waiting for you to
> load it, what actually happens is that Python tries to dynload
> _foo.cpython-32dmu.so and crashes miserably.  Why did it do that?
> 
> The reason is that the import.c logic that uses the struct filedescr tables
> built from _PyImport_DynLoadFiletab are just not smart enough to handle this
> case.  All it knows about are suffix, and for backwards compatibility, we have
> dynload_shlib.c matching both .SOABI.so *and* bare .so.  So when it's
> searching the directories for .cpython-32m.so files, it finds the
> ..cpython-32dmu.so first based on the bare .so match.

I don't understand -- wouldn't "foo.sometag.so" (where sometag is not SOABI)
only be found a match for a suffix of ".so" if the module name requested is
"foo.sometag"?  (And if not, isn't implementing that the easiest solution?)

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.