This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author twouters
Recipients twouters
Date 2013-01-31.21:54:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1359669296.59.0.227426586133.issue17095@psf.upfronthosting.co.za>
In-reply-to
Content
At some point (probably in 3.2) the support for shared modules built using Modules/Setup was broken, for two reasons:

 - Python no longer considers 'foomodule.so' when looking for a module called 'foo', but Modules/makesetup still appends 'module.so' for a 'foo' module.

 - Python no longer considers Modules/ to be the exec_prefix (and instead uses what was loaded from the build-info .txt written by setup.py) but the build process still leaves these Modules/Setup-built shared modules in the Modules directory (and it doesn't know about the directory setup.py will make, so it can't really do anything else.)

This patch fixes both problems, by making Modules/makesetup name shared library modules 'foo.so' and by adding the Modules subdirectory to sys.path (after the setup.py-provided directory) when running from the build directory. (The existing build process has no problem _installing_ the Modules/Setup-built extension modules, it's just Python that doesn't know how to find them.)
History
Date User Action Args
2013-01-31 21:54:56twouterssetrecipients: + twouters
2013-01-31 21:54:56twouterssetmessageid: <1359669296.59.0.227426586133.issue17095@psf.upfronthosting.co.za>
2013-01-31 21:54:56twouterslinkissue17095 messages
2013-01-31 21:54:56twouterscreate