Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Mime-Version:	1.0 (Apple Message framework v734)
Message-Id:	<1FA0F815-D70C-47E4-AEC0-AF21AC773F99@acm.org>
To:	cygwin AT cygwin DOT com
From:	John Whitley <whitley AT acm DOT org>
Subject:	Python extension package problem & root-cause
Date:	Thu, 15 Sep 2005 22:54:32 -0700
X-BlargAV-Status:	No viruses detected, BlargAV v1.1 on localhost.drteeth.p.blarg.net

The following is derived from a bug report that I've filed on Python  
that affects
building and installing extension packages on the Cygwin platform.   
I'm posting this here to assist any other Cygwin users affected by  
this problem.  URL for the Python bug
report is:

http://sourceforge.net/tracker/index.php? 
func=detail&aid=1289136&group_id=5470&atid=105470

-- John Whitley

----------

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.

Workaround:

The 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")


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -