[ python-Bugs-1289136 ] distutils extension library path bug on cygwin

SourceForge.net noreply at sourceforge.net
Tue Nov 1 14:16:16 CET 2005

Bugs item #1289136, was opened at 2005-09-12 14:04
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Whitley (jwhitley)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils extension library path bug on cygwin

Initial Comment:
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:

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


>Comment By: Jason Tishler (jlt63)
Date: 2005-11-01 04: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?


Comment By: John Whitley (jwhitley)
Date: 2005-10-28 09: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...)


Comment By: Jason Tishler (jlt63)
Date: 2005-10-28 04: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?


Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-23 18:47

Logged In: YES 

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

Maybe that will help you find the true canonical name?


Comment By: Jason Tishler (jlt63)
Date: 2005-09-16 04: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.


You can respond by visiting: 

More information about the Python-bugs-list mailing list