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.

Title: distutils extension library path bug on cygwin
Type: behavior Stage: resolved
Components: Distutils Versions: Python 3.1, Python 3.2, Python 2.7
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: tarek Nosy List: iritkatriel, jlt63, jwhitley, nnorwitz, tarek
Priority: normal Keywords:

Created on 2005-09-12 22:04 by jwhitley, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (7)
msg60809 - (view) Author: John Whitley (jwhitley) Date: 2005-09-12 22:04
A while back I reported a problem on the Cygwin mailing
list where all python extension packages would fail
"python 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:

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" +
          # building python standard extensions

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

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
msg60810 - (view) Author: Jason Tishler (jlt63) * (Python triager) Date: 2005-09-16 12:04
Logged In: YES 


Thanks for the excellent analysis!


Unfortunately, I'm not sure what is the best way to solve this
problem.  Does anyone have any suggestions? Thanks.
msg60811 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2005-10-24 02:47
Logged In: YES 

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

Maybe that will help you find the true canonical name?
msg60812 - (view) Author: Jason Tishler (jlt63) * (Python triager) Date: 2005-10-28 12:21
Logged In: YES 

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?
msg60813 - (view) Author: John Whitley (jwhitley) Date: 2005-10-28 17:29
Logged In: YES 

Jason is correct that readlink won't help.  On Cygwin
/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...)
msg60814 - (view) Author: Jason Tishler (jlt63) * (Python triager) Date: 2005-11-01 13:16
Logged In: YES 

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?
msg381042 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2020-11-15 23:12
I see that the erroneous "is string.find..." condition is no longer in the code:

Is this issue out of date or is there something still to do on it?
Date User Action Args
2022-04-11 14:56:13adminsetgithub: 42365
2020-12-19 00:35:17iritkatrielsetstatus: pending -> closed
resolution: out of date
stage: needs patch -> resolved
2020-11-15 23:14:54iritkatriellinkissue1465554 superseder
2020-11-15 23:12:57iritkatrielsetstatus: open -> pending
nosy: + iritkatriel
messages: + msg381042

2010-08-21 19:27:33BreamoreBoysetassignee: tarek
stage: needs patch
versions: + Python 3.1, Python 2.7, Python 3.2
2009-02-10 16:55:12akitadasetnosy: + tarek
type: behavior
2005-09-12 22:04:55jwhitleycreate