homepage

The Cygwin build is failing during make install -- specifically, during the regen step:
[snip]
mkdir /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.Lib/plat-cygwin
cp /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.Lib/plat-generic/regen /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.Lib/plat-cygwin/regen
export PATH; PATH="`pwd`:$PATH"; \
export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; \
export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \
export EXE; EXE=".exe"; \
cd /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.Lib/plat-cygwin; ./regen
python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ImportError: No module named encodings
./regen: line 3: 2976 Aborted (core dumped) python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h
[snip]
Note that I seem to be running into the same or similar problem as the following:
http://bugs.python.org/issue3626#msg72415
I was able to workaround the core dump problem with the following patch:
diff -u Python-2.6.5.orig/Makefile.pre.in Python-2.6.5/Makefile.pre.in
--- Python-2.6.5.orig/Makefile.pre.in 2009年12月24日 09:19:38.000000000 -0500
+++ Python-2.6.5/Makefile.pre.in 2010年04月13日 17:05:04.368555900 -0400
@@ -910,7 +910,7 @@
 mkdir $(srcdir)/Lib/$(PLATDIR)
 cp $(srcdir)/Lib/plat-generic/regen $(srcdir)/Lib/$(PLATDIR)/regen
 export PATH; PATH="`pwd`:$$PATH"; \
- export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; \
+ export PYTHONPATH; PYTHONPATH="$(srcdir)/Lib"; \
 export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \
 export EXE; EXE="$(BUILDEXE)"; \
 cd $(srcdir)/Lib/$(PLATDIR); $(RUNSHARED) ./regen
Note that I'm building outside of the source tree, so when the original version sets PYTHONPATH to the following:
"`pwd`/Lib"
it was guaranteed to point to a nonexistent directory.
Unfortunately, now the build fails as follows:
[snip]
mkdir /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.Lib/plat-cygwin
cp /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.Lib/plat-generic/regen /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.Lib/plat-cygwin/regen
export PATH; PATH="`pwd`:$PATH"; \
export PYTHONPATH; PYTHONPATH="/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib"; \
export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \
export EXE; EXE=".exe"; \
cd /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.Lib/plat-cygwin; ./regen
python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Traceback (most recent call last):
 File "/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.Lib/sysconfig.py", line 334, in _init_posix
 _parse_makefile(makefile, vars)
 File "/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.Lib/sysconfig.py", line 220, in _parse_makefile
 with open(filename, errors="surrogateescape") as f:
IOError: [Errno 2] No such file or directory: '/usr/lib/python3.2/config-3.2m/Makefile'
[snip]
AFAICT, the problem is when regen runs, python thinks it is running out of an installation directory and not a build directory.
Does anyone know how to convince python to think it is running out its build directory even though it is being found in the PATH. If not, does anyone have any other suggestions on how to resolve this problem?

The problem is due to Cygwin's automatic ".exe" extension handling. See the attached patch (i.e., code comment) for the details. Is this patch acceptable?

I use obcaseinsensitive=0, hence I didn't see this. Would that be an option for you?

No activity since 2012, I close the issue.