[issue3375] _multiprocessing.so build problems

Guido van Rossum report at bugs.python.org
Thu Jul 17 07:06:29 CEST 2008


Guido van Rossum <guido at python.org> added the comment:

The order thing was a red herring.  However, I understand what's going
on now.  Somebody else can fix it hopefully.

So what's going on:  In the Python instance that runs setup.py,
importing _multiprocessing fails.  But if I start a new Python instance
in exactly the same environment, it works.  Why?  Because at the *start*
of running setup.py, the directory .../build/lib.macosx-10.3-i386-3.0
doesn't exist, and this is being cached in sys.path_importer_cache,
which has a NullImporter instance for that key.  Maybe the solution is
to remove that cache entry (if it exists) in the code that creates that
directory?

I found this by (a) disabling the two except clauses in setup.py that
catch exceptions from the attempt to import the module that was just
built, and (b) adding a -i flag to the Python instance invoked by the
Makefile to run setup.py.  This gave me an interactive interpreter at
the moment the "import _multiprocessing" failed.  Poking around I could
see that sys.path_importer_cache had a NullImporter instance for the
directory from which _multiprocessing.so was to be imported.  I could
even delete that cache entry, and then the import would pass!

Good luck fixing...

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3375>
_______________________________________


More information about the Python-bugs-list mailing list