[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