A while back I reported a problem on the Cygwin mailing
list where all python extension packages would fail
"python setup.py install" at the link step due to a
mangled lib dir (-L) option.  distutils was producing a
link line with "-L.", instead of the desired
"-L/usr/lib/python2.4/config".  I've finally rooted out
the cause of this problem.

The relevant code is the if-block starting at line 188 of:
  /usr/lib/python2.4/distutils/command/build_ext.py

I've reproduced that block here for clarity of
discussion (indentation truncated for redability)

  if sys.platform[:6] == 'cygwin' or sys.platform[:6]
== 'atheos':
      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('.')

The test "string.find(...) != -1" attempts to test
whether "/usr" appears in the full executable name. 
This incorrectly fails in the case that /bin is in the
user's path before /usr/bin.  (i.e.
string.find("/bin/python","/usr") == -1)  Note that a
vagary of Cygwin is that /usr/bin is a Cygwin mount to
/bin.

The user-side workaround is to ensure that /usr/bin
appears in your path before /bin.  It looks like a new
and improved Cygwin special case test is needed to fix
this problem; I'm not sure offhand what the best case
would be.  Perhaps an outright test as follows would work:
   sys.executable.startswith(sys.exec_prefix) or
sys.executable.startswith(os.sep+"bin")

Logged In: YES 
user_id=86216

John,

Thanks for the excellent analysis!

All,

Unfortunately, I'm not sure what is the best way to solve this
problem.  Does anyone have any suggestions? Thanks.

Logged In: YES 
user_id=33168

What does os.readlink(sys.executable) return?

Maybe that will help you find the true canonical name?

Logged In: YES 
user_id=86216

Unfortunately, I don't think readlink will help.

I was thinking of comparing inodes, but AFAICT inodes
under Cygwin are not guaranteed to be unique for all
platforms and filesystems.

So, maybe John's check is the only reliable option?

Logged In: YES 
user_id=649097

Jason is correct that readlink won't help.  On Cygwin
installations,
/bin and /usr/bin are not symlinks, they're aliases in
Cygwin's default mount system.  (C:\cygwin on / (root) and
C:\cygwin\bin on /usr/bin)  The Python 2.4.1 docs says:
"readlink(path)  Return a string representing the path to
which the symbolic link points."  For good measure, I
confirmed that readlink doesn't give the desired results.

The bigger problem that I see is that this code is using
hard-coded automagic path detection to figure out something
that it should be told explicitly.  That is, "are we in the
special case of building python's own libraries/extensions."
 (versus trying to install an extension to an existing
python installation.)

To illustrate the problem, both my proposal and the original
code are broken for trying to build python in /usr/local. 
(e.g. build under /usr/local/src -- thinks it's an install
not a build due to "/usr" prefix...)

Logged In: YES 
user_id=86216

I agree with John -- distutils needs to know whether it is
building Python itself or just a extension module. I can
think of the following ways to this accomplish this:

1. Check sys.path
2. Use some of the checks in Modules/getpath.c

Any thoughts about which approach would be better?
Any other ideas?

I see that the erroneous "is string.find..." condition is no longer in the code: 
https://github.com/python/cpython/blob/master/Lib/distutils/command/build_ext.py#L220


Is this issue out of date or is there something still to do on it?