[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

Thanks for the patch, adapted to current trunk and applied in rev. 54331, 54332 (2.5).