[Python-Dev] issue 9807 - a glitch in coexisting builds of different types (original) (raw)

Georg Brandl g.brandl at gmx.net
Sat Oct 2 12:36:21 CEST 2010

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 PyImportDynLoadFiletab are just not smart enough to handle this case. All it knows about are suffix, and for backwards compatibility, we have dynloadshlib.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.

More information about the Python-Dev mailing list