Issue 1569798: Fix building the source within exec_prefix (original) (raw)

[forwarded from http://bugs.debian.org/385336]

when built under a subdirectory of exec_prefix, the build fails building the extensions.

bug submitter writes:

OK, after a debugging session, I found out why. It seems to be an upstream bug in distutils. See python2.5-2.5~c1/Lib/distutils/command/build_ext.py line 188+:

if string.find(sys.executable, sys.exec_prefix) != -1: # building third party extensions self.library_dirs.append(os.path.join(sys.prefix, "lib", "python" + get_python_version(), "config")) else: # building python standard extensions self.library_dirs.append('.')

This code is executed only in the shared build. The if clause is here to determine whether we're running a correctly installed python or whether we're running python from its source tree. In our case (since we're building python itself atm), the condition must evaluate to false. However, this exact check looks very clumsy.

On my build system, sys.executable == '/usr/src/debian/build/python2.5-2.5~c1/build-shared/python', sys.exec_prefix == '/usr', i.e. the condition is true and distutils thinks it's running on an already installed python distribution. The reason is that I'm building below the 'install prefix' directory (in /usr/src/...).

In contrast, on the Debian buildd machines, this is performed in /build/buildd/.... which does not trigger the distutils bug.

Logged In: YES user_id=140916

Hi, I seem to have a very related problem too, since i also traced it back to Lib/distutils/command/build_ext.py line 188. Summary, when Python is installed with both --enable-shared and --prefix, distutils generated compilations lines (rightly) add -lpython2.5 but does NOT add the corresponding -L (which is, PREFIX/lib by default ). I had to manually add self.library_dirs.append(os.path.join(sys.prefix, "lib")) on line 190 to quick fix that.

Also, the abovementioned test "string.find(sys.executable, sys.exec_prefix)!=-1" doesn't have the intended effect on my system either, because of symlinks (oddly enough it works when running from IPython, maybe it resolves paths differently)

Thanks