[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Jason Tishler <[EMAIL PROTECTED]> added the comment: There have been three different regular expressions proposed to resolve this issue: 1. http://bugs.python.org/issue2234 2. http://bugs.python.org/issue3013 3. http://cygwin.com/ml/cygwin/2008-05/msg00622.html Does anyone know which one is best? I would like to release a patched Cygwin Python 2.5.2 that resolves this issue, but I feel we should reach consensus on what regular expression to use before I do so. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2234> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Jason Tishler <[EMAIL PROTECTED]> added the comment: I tested the regular expression in #3: (\d+\.\d+(\.(\d+))?([ab](\d+))?) and it worked for both '2.18.50.20080523' & '1.2.3a'. Additionally, it worked for the following test cases that I tried: 2.18.50a.20080523 2.18.50a 20080523 2.18.50 20080523 1.2.3 Unfortunately, I don't know what is the set of all possible version formats that "ld -v" can return. So, I don't know how to devise a regular expression guaranteed to work for all ld versions including future ones. AFAICT, we have only two options to resolve this issue: 1. Improve the regular expression as best we can and continue to change it as necessary in the future. 2. Remove the fragile version checking all together and make an explicit decision to only support modern binutils. Any opinions? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2234> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Jason Tishler <[EMAIL PROTECTED]> added the comment: cygwinccompiler.py only uses the first group: $ fgrep group cygwinccompiler.py gcc_version = StrictVersion(result.group(1)) ld_version = StrictVersion(result.group(1)) dllwrap_version = StrictVersion(result.group(1)) So, I would like to move forward with the regular expression from http://cygwin.com/ml/cygwin/2008-05/msg00622.html: (\d+\.\d+(\.(\d+))?([ab](\d+))?) Can we get a consensus? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2234> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Jason Tishler <[EMAIL PROTECTED]> added the comment: Thanks! ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2234> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706863] Failed to build Python 2.5.1 with sqlite3
Jason Tishler <[EMAIL PROTECTED]> added the comment: The Cygwin build is having the same problem: http://cygwin.com/ml/cygwin/2008-09/msg00145.html In this case, the sqlite3 libraries are installed (in /usr/lib), but their suffixes do not match the expected values. Does anyone know the best way to make setup.py and/or distutils search for .dll.a instead of .dll? -- nosy: +jlt63 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1706863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706863] Failed to build Python 2.5.1 with sqlite3
Jason Tishler <[EMAIL PROTECTED]> added the comment: The Cygwin build issue was worked around by releasing a sqlite3 package that contains a static library too. However, this causes the Python _sqlite module to be statically linked against sqlite3 even though a shared library version is available. The following patch enables Cygwin to leverage off on the ".dylib" functionality added (AFAICT) for Mac OS X. After the patch is applied, the _sqlite module is linked against the shared sqlite3 library instead of the static one. Is the patch acceptable? Or, can someone think of a better approach? Added file: http://bugs.python.org/file11575/unixccompiler.py.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1706863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706863] Failed to build Python 2.5.1 with sqlite3
Jason Tishler <[EMAIL PROTECTED]> added the comment: Hirokazu Yamamoto wrote: > Python is not using CCygwinCCompiler to build itself on cygwin. Which I why my patch modifies UnixCCompiler instead of CCygwinCCompiler. FWIW, my patch leverages the already existing Cygwin specific code in UnixCCompiler. So, is my patch acceptable? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1706863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2445] Use The CygwinCCompiler Under Cygwin
Jason Tishler <[EMAIL PROTECTED]> added the comment: I don't think the patch, cygwin-smaller.diff, is correct. The value of static_lib_extension needs to remain ".a". Otherwise, shared extensions attempting to build against a library that only offers a static version will fail to link. AFAICT, Cygwin needs a concept that is not currently supported by distutils -- the ability to specify a shared library *link* extension (i.e., ".dll.a") which is different from the shared library extension (i.e., ".dll"). On Unix they are the same (e.g., ".so"), but on Cygwin they are different because of how Windows handles DLLs -- import library versus DLL. -- nosy: +jlt63 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2445> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706863] Failed to build Python 2.5.1 with sqlite3
Jason Tishler <[EMAIL PROTECTED]> added the comment: Hirokazu Yamamoto wrote: > Umm, it works, but I'm not sure we can call import library as > dylib... Agreed. > I had considered attached patch "experimental_distutils.patch". > It's little adhoky, I'm not sure this patch is acceptable. The new functionality is very similar to what I suggested in issue2445. Although it would be better to put Cygwin specific behavior in CygwinCCompiler, I think the changes would have be more invasive if you did. I prefer your approach to mine. Can we get consensus and move forward? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1706863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1005895] curses for win32
Jason Tishler added the comment: Sorry, but I don't know. I haven't looked at this issue for almost five years! And when I did, I only looked as far to determine it wasn't Cygwin related. -- ___ Python tracker <http://bugs.python.org/issue1005895> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail
New submission from Jason Tishler: Makefile.pre.in contains extra slash before $(DESTDIR) in two locations as in the following: sharedinstall: $(RUNSHARED) ./$(BUILDPYTHON) -E $(srcdir)/setup.py install \ --prefix=$(prefix) \ --install-scripts=$(BINDIR) \ --install-platlib=$(DESTSHARED) \ --root=/$(DESTDIR) This causes Cygwin builds to fail if DESTDIR is set as follows: creating //tmp error: could not create '//tmp': No such host or network path The following Open Group Specification: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html indicates the following: 4.11 Pathanme Resolution [snip] A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner,... IMO, these extra slashes should be removed as indicated in the attached patch. OK to commit? If so, to which branches? -- assignee: jlt63 components: Build files: python.patch keywords: patch, patch messages: 63256 nosy: jlt63 priority: low severity: normal status: open title: Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail type: compile error versions: Python 2.5 Added file: http://bugs.python.org/file9603/python.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2233> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail
Changes by Jason Tishler: __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2233> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Jason Tishler <[EMAIL PROTECTED]> added the comment: If the version is guaranteed to be x.y or x.y.z, then the patch seems correct. Note I am not set up to test this patch and it has been years since I have looked at this part of the code base. Sorry, that I can't be more helpful. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2234> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail
Jason Tishler added the comment: Sorry for the delay, but I was on vacation and then recovering from vacation... You are correct that my initial patch does not handle the case when DESTDIR is not specified. Your suggestion will work, but seems hacky. What about adding the defaulting of DESTDIR to "/" to my initial patch? This seems cleaner. See my second patch for the details. If this approach is acceptable, then feel free to move the defaulting of DESTDIR to a more appropriate place in Makefile.pre.in. I wasn't sure where to put this change. Added file: http://bugs.python.org/file12652/Makefile.pre.in.diff ___ Python tracker <http://bugs.python.org/issue2233> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail
Jason Tishler added the comment: Obviously not... :,( It seems like we might have to go with your "/./" workaround, but let me see if I can come up with another approach. ___ Python tracker <http://bugs.python.org/issue2233> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail
Jason Tishler added the comment: Your latest patch is on the right track, but see my latest one, Makefile.pre.in.v2.diff, for an optimization. I tested make install with and without DESTDIR defined on the command line and both cases behaved as expected. Added file: http://bugs.python.org/file12741/Makefile.pre.in.v2.diff ___ Python tracker <http://bugs.python.org/issue2233> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail
Jason Tishler added the comment:
I guess you mean the following:
${var:-value}
Old BSD shells, including the Ultrix sh, don't accept the colon for
any shell substitution, and complain and die.
If so, should we just go forward without the colon? The bash manpage
indicates the following:
In each of the cases below, ... bash tests for a parameter that is
unset or null; omitting the colon results in a test only for a
parameter that is unset.
So, if a user executes "make DESTDIR= install", then the build will
fail. Or, maybe we shouldn't worry about that corner case.
What do you think?
___
Python tracker
<http://bugs.python.org/issue2233>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue786827] IDLE starts with no menus (Cygwin)
Jason Tishler added the comment: AFAICT, this issue is resolved in the latest Cygwin Python package (i.e., 2.6.7-1) that is built against a X11-based Tcl/Tk instead of a Win32 GDI version: http://cygwin.com/ml/cygwin-announce/2012-02/msg00014.html -- ___ Python tracker <http://bugs.python.org/issue786827> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue786827] IDLE starts with no menus (Cygwin)
Jason Tishler added the comment: Please do. When I tested the Cygwin Python 2.6.7-1 release, IDLE was one of my testcases. In my limited testing (I'm not a regular IDLE user), the menus appeared to function properly. -- ___ Python tracker <http://bugs.python.org/issue786827> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13756] Python3.2.2 make fail on cygwin
Jason Tishler added the comment: I offer the attached patch for consideration. AFAICT, only the Makefile.pre.in and build_ext.py changes are required. I included the makesetup change for completeness and to be consistent with the other changes. -- keywords: +patch nosy: +jlt63, yselkowitz Added file: http://bugs.python.org/file25936/3.2.3-libpython-abi.patch ___ Python tracker <http://bugs.python.org/issue13756> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15047] Cygwin install (regen) problem
New submission from Jason Tishler : 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.2.3/Lib/plat-cygwin cp /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-generic/regen /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.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.2.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 Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 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.0 -0500 +++ Python-2.6.5/Makefile.pre.in2010-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.2.3/Lib/plat-cygwin cp /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-generic/regen /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.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.2.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 Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Traceback (most recent call last): File "/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.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.2.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? -- components: Build messages: 162634 nosy: jlt63, yselkowitz priority: normal severity: normal status: open title: Cygwin install (regen) problem versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue15047> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15047] Cygwin install (regen) problem
Jason Tishler added the comment: 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? -- keywords: +patch stage: -> patch review type: -> behavior Added file: http://bugs.python.org/file26009/3.2.3-extension.patch ___ Python tracker <http://bugs.python.org/issue15047> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13756] Python3.2.2 make fail on cygwin
Jason Tishler added the comment: > Is this still an issue on 3.3/3.4? I presume so. > Does the patch still work? I haven't tried it on 3.3 yet, so I don't know if it will apply cleanly. -- ___ Python tracker <http://bugs.python.org/issue13756> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail
Jason Tishler added the comment: AFAICT, yes. -- ___ Python tracker <http://bugs.python.org/issue2233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
