[issue17226] libintl should also check for libiconv
Change by Jeffrey Armstrong : -- nosy: -Jeffrey.Armstrong ___ Python tracker <https://bugs.python.org/issue17226> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11723] Add support for mingw64 compiler
Change by Jeffrey Armstrong : -- nosy: -Jeffrey.Armstrong ___ Python tracker <https://bugs.python.org/issue11723> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20596] Support for alternate wcstok syntax for Windows compilers
Change by Jeffrey Armstrong : -- nosy: -Jeffrey.Armstrong ___ Python tracker <https://bugs.python.org/issue20596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23876] Fix mkdir() call for Watcom compilers on UNIX-like platforms
Change by Jeffrey Armstrong : -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue23876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29936] Typo in __GNU*C*_MINOR__ guard affecting gcc 3.x
Changes by Jeffrey Armstrong : -- nosy: -Jeffrey.Armstrong ___ Python tracker <http://bugs.python.org/issue29936> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24769] Interpreter doesn't start when dynamic loading is disabled
Jeffrey Armstrong added the comment: I pulled the 3.5 branch a few minutes ago, and the patch isn't present. Has it not been pushed to hg.python.org? -- ___ Python tracker <http://bugs.python.org/issue24769> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24217] O_RDWR undefined in mmapmodule.c
Jeffrey Armstrong added the comment: There is a patch attached to this report for greater than 2 months. Should I mark this as "won't fix?" -- ___ Python tracker <http://bugs.python.org/issue24217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24769] Interpreter doesn't start when dynamic loading is disabled
New submission from Jeffrey Armstrong: When attempting to build Python without dynamic loading (HAVE_DYNAMIC_LOADING is not defined), the module "_imp" will not have the function "exec_dynamic." However, Lib/bootstrap.py seems to assume that "_imp.exec_dynamic" exists, causing the error: ./python -E -S -m sysconfig --generate-posix-vars ;\ if test $? -ne 0 ; then \ echo "generate-posix-vars failed" ; \ rm -f ./pybuilddir.txt ; \ exit 1 ; \ fi Traceback (most recent call last): File "", line 1134, in _install File "", line 1114, in _setup File "", line 1082, in _builtin_from_name File "", line 673, in _load_unlocked File "", line 748, in exec_module AttributeError: module '_imp' has no attribute 'exec_dynamic' Fatal Python error: Py_Initialize: importlib install failed Current thread 0x (most recent call first): ABNORMAL TERMINATION generate-posix-vars failed when trying to build. This error means that Python 3.5 will not be able to build in a purely static (no dynamic loading whatsoever) form. This error was encountered in Python 3.5b4. -- components: Build messages: 247797 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: Interpreter doesn't start when dynamic loading is disabled type: compile error versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue24769> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24217] O_RDWR undefined in mmapmodule.c
Changes by Jeffrey Armstrong : Removed file: http://bugs.python.org/file39407/mmapmodule.py3.5.0a3.diff ___ Python tracker <http://bugs.python.org/issue24217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24217] O_RDWR undefined in mmapmodule.c
Jeffrey Armstrong added the comment: Indeed, I agree. Let's try this new patch. -- Added file: http://bugs.python.org/file39408/mmapmodule.py3.5.0a3.HAVE_FCNTL_H.diff ___ Python tracker <http://bugs.python.org/issue24217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21931] Nonsense errors reported by msilib.FCICreate for bad argument
Jeffrey Armstrong added the comment: I thought, while I'm here reporting another bug, I'd bump this once more. There is a patch here, and it corrects clearly broken code. Should I mark this as "won't fix?" -- ___ Python tracker <http://bugs.python.org/issue21931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20596] Support for alternate wcstok syntax for Windows compilers
Changes by Jeffrey Armstrong : -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue20596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24217] O_RDWR undefined in mmapmodule.c
New submission from Jeffrey Armstrong: While compiling on Linux/x86 with Open Watcom, I've run into the following at link time in Modules/mmapmodule.c: ./Modules/mmapmodule.c(1223): Error! E1011: Symbol 'O_RDWR' has not been declared The constant isn't defined because fcntl.h isn't included. Looking at the top of the file, it appears that, for the Apple platform only, this header is included, but no others. In order to support more runtime libraries outside of GNU libc, I would suggest including fcntl.h for all UNIX-y platforms, especially because the POSIX standard dictates that this constant be defined in fcntl.h. I don't know how it finds its way in under GCC/GNU libc, but an explicit include might be better. -- components: Extension Modules files: mmapmodule.py3.5.0a3.diff keywords: patch messages: 243404 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: O_RDWR undefined in mmapmodule.c type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file39407/mmapmodule.py3.5.0a3.diff ___ Python tracker <http://bugs.python.org/issue24217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23877] Build fails when threads are disabled during configure step
Jeffrey Armstrong added the comment: Oops, I meant WITH_THREAD. Thanks for the quick fix! -- ___ Python tracker <http://bugs.python.org/issue23877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23877] Build fails when threads are disabled during configure step
New submission from Jeffrey Armstrong: If threads are disabled, either via --disable-threads or using a compiler/standard library that doesn't support threads, the build will fail when linking the Python interpreter because the following is undefined: PyGILState_GetThisThreadState The error is caused by a change since 3.5.0a1 that uses a call to this function in Python/pylifecycle.c:1303 without first checking if the WITH_THREADS macro is defined. If WITH_THREADS is undefined, the function PyGILState_GetThisThreadState is not built. I've attached a simple patch correcting the issue, but it should be trivial to add a simple macro check around the call. -- components: Interpreter Core files: pylifecycle-threads-3.5.0a3.patch keywords: patch messages: 240154 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: Build fails when threads are disabled during configure step type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file38844/pylifecycle-threads-3.5.0a3.patch ___ Python tracker <http://bugs.python.org/issue23877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23876] Fix mkdir() call for Watcom compilers on UNIX-like platforms
New submission from Jeffrey Armstrong: Within Modules/posixmodule.c:4914 (in 3.5.0a3), the preprocessor checks for compiler macros as such: #if ( defined(__WATCOMC__) || defined(PYCC_VACPP) ) && !defined(__QNX__) result = mkdir(path->narrow); #else result = mkdir(path->narrow, mode); #endif The purpose of the code was to detect if we're compiling using Watcom, but not on QNX, or VisualAge as our compiler, where mkdir() wouldn't accept a mode. However, Watcom supports Linux as well and properly implements the mode argument, causing the compilation to fail. The proper check, rather than looking for "!defined(__QNX__)" would be "!defined(__UNIX__)," which would allow the code to properly compile using Watcom on either Linux or QNX: #if ( defined(__WATCOMC__) || defined(PYCC_VACPP) ) && !defined(__UNIX__) result = mkdir(path->narrow); #else result = mkdir(path->narrow, mode); #endif FYI, in Watcom, the __UNIX__ macro is defined on both Linux and QNX, so this change will not break code for people who are still using Watcom to build Python for QNX (which is probably nobody at all). There are two other places where the __QNX__ macro should be replaced in Modules/posixmodule.c, and the attached patch fixes both. -- components: Interpreter Core files: watcom_qnx_to_unix-3.5.0a3.patch keywords: patch messages: 240153 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: Fix mkdir() call for Watcom compilers on UNIX-like platforms type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file38843/watcom_qnx_to_unix-3.5.0a3.patch ___ Python tracker <http://bugs.python.org/issue23876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20597] PATH_MAX already defined on some Windows compilers
Jeffrey Armstrong added the comment: What's to understand? Some compilers, particularly MinGW and Open Watcom, already define a PATH_MAX macro on Windows, and it's not necessarily the same as Python's redefinition of it, possibly causing a compiler error. That's all. Given the time frame that this bug has existed (9 months!?!) and its trivial fix, which would involve adding an "#ifndef PATH_MAX" right before its declaration, I think "won't fix" is an appropriate resolution. Leave it open or don't, it makes little difference to me as I'm no longer interested. -- ___ Python tracker <http://bugs.python.org/issue20597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20597] PATH_MAX already defined on some Windows compilers
Changes by Jeffrey Armstrong : -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue20597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21931] Nonsense errors reported by msilib.FCICreate for bad argument
Jeffrey Armstrong added the comment: There's not much to look into. If the Python function encounters an argument error, it returns an uninitialized integer as an "error code." This patch fixes incorrect C code, nothing more. -- ___ Python tracker <http://bugs.python.org/issue21931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors
Jeffrey Armstrong added the comment: The last "official" Open Watcom release (1.9) is indeed quite dated. The codebase was forked for a variety of reasons where development continues: https://github.com/open-watcom/open-watcom-v2 The current development release does indeed build on x86_64 (the build system is quite complicated). I'm running Open Watcom nightly builds on Debian Wheezy x86 myself. I've mentioned supporting OW in Python, most notably in a PyCon lightning talk last year, but there really seems to be no interest even if there are some benefits. OW allows building the full interpreter and standard library on Windows, for example, without any MS tooling. I was using it in this particular case as a benchmark for compile times for a presentation in a few weeks. OW is able to build the interpreter in ~25sec whereas GCC is taking 1min 10sec on my desktop. I don't have any plans to pursue Python support for OW any further, although I'm open to the idea. This patch is enough to compile *this portion* of Modules/posixmodule.c with OW, but, no, it is not sufficient to compile the whole file. There are two more places where some preprocessor definitions cause issues. One is OW-specific, and I don't plan on filing a bug against it. The other is #22579. I only filed this bug because the code was broken. -- ___ Python tracker <http://bugs.python.org/issue22568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors
Jeffrey Armstrong added the comment: Georg: Sorry, that wasn't directed at you. Your comment snuck in before mine. It was more general frustration. -- ___ Python tracker <http://bugs.python.org/issue22568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors
Jeffrey Armstrong added the comment: My patch merely fixes broken code that wasn't being used by Python's "supported" compilers under most common configurations. It's really independent of compiler. I realize nobody here cares about Open Watcom as a supported compiler; the Python community has made that *abundantly* clear. -- ___ Python tracker <http://bugs.python.org/issue22568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22579] Posix module init function name should not be compiler-dependent
New submission from Jeffrey Armstrong: The determination of the name of the posix module's initialization function (at Modules/posixmodule.c:12055) is currently dependent on the compiler being used. For MSVC, Watcom, or Borland, the name is defined as "PyInit_nt." However, both Open Watcom and Borland have shipped compilers for GNU/Linux (and other platforms), making determining the posix module initialization function based on compiler incorrect. Most other places in Modules/posixmodule.c correctly use the "MS_WINDOWS" preprocessor definition to determine if Windows routines should be used. Naming the intialization function for the posix module should be dependent on this as well rather than compiler identifiers. Linking the interpreter natively with Open Watcom fails under GNU/Linux due to "PyInit_posix" being undefined. This occurs because of the reasons described above. The patch included corrects the issue. -- components: Interpreter Core files: posix_init.patch keywords: patch messages: 228789 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: Posix module init function name should not be compiler-dependent type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file36835/posix_init.patch ___ Python tracker <http://bugs.python.org/issue22579> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors
Jeffrey Armstrong added the comment: So in my original report, I actually got things backwards. The failure is because utime is a local variable, but a call to utime() is then attempted. Regardless, the code is still completely broken in Modules/posixmodule.c under the conditions I described. -- ___ Python tracker <http://bugs.python.org/issue22568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors
Jeffrey Armstrong added the comment: Under the conditions I described in Modules/posixmodules.c on line 4815, the utime() function is called. With the current code, the following correct compiler error is emitted: ./Modules/posixmodule.c(4815): Error! E1012: Expression is not a function The above occurs because utime is treated as a local variable and an attempt is made at calling it as a function. The use of a possible (and fairly standard) function name as a local variable is unfortunate, and I'm guessing these conditions haven't been tested in a while. -- ___ Python tracker <http://bugs.python.org/issue22568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22568] Use of "utime" as variable name in Modules/posixmodule.c causes errors
New submission from Jeffrey Armstrong: Under certain circumstances, Modules/posixmodule.c will fail to compile due to a number of utime-related functions using a variable named "utime" when a function named "utime" already exists in the compiler's C header files. Specifically, if the following are undefined: HAVE_UTIMENSAT HAVE_UTIMES and the following are defined: HAVE_UTIMENSAT HAVE_LUTIMES HAVE_UTIME_H the compiler will fail because the UTIME_TO_UTIMBUF module attempts to access utime->now when utime is acutually a function included from utime.h. I've attached a patch that renames the uname functions' parameter "utime" to "ut" to avoid the conflict. This bug was encountered using Open Watcom 2.0 (owcc) under GNU/Linux 32-bit. -- components: Interpreter Core files: utime-3.4.1.patch keywords: patch messages: 228690 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: Use of "utime" as variable name in Modules/posixmodule.c causes errors type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file36825/utime-3.4.1.patch ___ Python tracker <http://bugs.python.org/issue22568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20597] PATH_MAX already defined on some Windows compilers
Jeffrey Armstrong added the comment: Was this ever accepted? -- ___ Python tracker <http://bugs.python.org/issue20597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21931] Nonsense errors reported by msilib.FCICreate for bad argument
Jeffrey Armstrong added the comment: Is this patch going to be accepted? It fixes actual incorrect code in msilib, and it seems to have stagnated -- ___ Python tracker <http://bugs.python.org/issue21931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17391] _cursesmodule Fails to Build on GCC 2.95 (static)
Jeffrey Armstrong added the comment: Next time I see a bug I'll be sure to wait rather than actually submit a patch... -- ___ Python tracker <http://bugs.python.org/issue17391> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19355] Initial modernization of OpenWatcom support
Jeffrey Armstrong added the comment: This patch is so old at this point, it doesn't apply. Obviously its contents are of no interest to anyone. -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue19355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21931] Nonsense errors reported by msilib.FCICreate for bad argument
Jeffrey Armstrong added the comment: Attached a patch. The dangers of using goto... -- keywords: +patch Added file: http://bugs.python.org/file35935/_msi.3.4.0.patch ___ Python tracker <http://bugs.python.org/issue21931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21931] Nonsense errors reported by msilib.FCICreate for bad argument
New submission from Jeffrey Armstrong:
The function fcicreate in PC/_msi.c can return nonsense if the list of files
passed to msilib.FCICreate does not contains tuples as expected. To replicate,
import msilib
msilib.FCICreate("test.cab", ["entry.txt"])
The above code will return a ValueError of the format:
ValueError: FCI error 11260524
The error code is meaningless. If one were to examine the code, you can see in
PC/_msi.c:246 (in "current"):
if (!PyArg_ParseTuple(item, "ss", &filename, &cabname))
goto err;
If we look at the error handler at PC/_msi.c:262, it assumes that one of the
Windows MSI API calls had failed, and will print the contents of the ERF error
structure:
err:
PyErr_Format(PyExc_ValueError, "FCI error %d", erf.erfOper); /* XXX better
error type */
In the case where the list does not contain tuples, the value of erf.erfOper
was never initialized or set because the error being raised is not due to the
Windows MSI API. The error is highly misleading as it is simply an argument
error.
--
components: Extension Modules
messages: 222458
nosy: Jeffrey.Armstrong
priority: normal
severity: normal
status: open
title: Nonsense errors reported by msilib.FCICreate for bad argument
type: behavior
versions: Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue21931>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20596] Support for alternate wcstok syntax for Windows compilers
Jeffrey Armstrong added the comment: I didn't receive any feedback on the last patch from 2014-02-12. Is this issue effectively dead? -- ___ Python tracker <http://bugs.python.org/issue20596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20596] Support for alternate wcstok syntax for Windows compilers
Jeffrey Armstrong added the comment: I've included a revised patch that is far simpler than the others I've proposed. In this example, the preprocess checks for MSVC or Borland/Embarcadero and, if found, uses three-argument wcstok_s(). If neither is detected, it checks for MinGW and, if found, defaults to old two-argument wcstok(). Otherwise, it defaults to three-argument wcstok(). The default in this case effectively encompasses all other OSes where POSIX-like wcstok() is available. Additionally, it also allows this default for Open Watcom on Windows or any other theoretically possible compilers on Windows that may provide this more common wcstok() syntax. -- Added file: http://bugs.python.org/file34063/wcstok.default.patch ___ Python tracker <http://bugs.python.org/issue20596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20596] Support for alternate wcstok syntax for Windows compilers
Jeffrey Armstrong added the comment: I know that Borland/Embarcadero also uses the two-argument version like Microsoft. As I said earlier, MinGW uses the two-argument version, although it is currently marked as deprecated. Just from searching, it appears that Pelles C/LCC uses the POSIX-like three-argument version. I'm having trouble thinking of any further Windows C compilers at the moment. The purpose of wrapping the definition in MS_WINDOWS originally was to preserve any behavior that already existed when building with a compiler that uses the two-argument version on Windows without any explicit case being called out for said compiler. -- ___ Python tracker <http://bugs.python.org/issue20596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20596] Support for alternate wcstok syntax for Windows compilers
Jeffrey Armstrong added the comment: Based on the comments thus far, I've gone ahead with another version of this patch. Py_WCSTOK is now defined regardless of OS. For Windows, it chooses between MSVC's wcstok_s, Open Watcom's wcstok, and MinGW's/misc's two-argument wcstok. If the platform isn't Windows, it defaults to the POSIX-like three-argument wcstok (same as Open Watcom's, actually). The wcstok functionality is really only used in three places: PC/getpathp.c, Modules/getpath.c, and Modules/main.c. This patch changes the calls to Py_WCSTOK in all cases. I appreciate the consideration and input this patch is receiving. -- Added file: http://bugs.python.org/file34055/wcstok.default.patch ___ Python tracker <http://bugs.python.org/issue20596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20597] PATH_MAX already defined on some Windows compilers
Jeffrey Armstrong added the comment: PATH_MAX is defined in both Open Watcom and MinGW's GCC toolchain. Neither is a "supported" compiler, I suppose. I hadn't meant to suggest that it be included in 3.4's release candidate, only that the problem exists on current versions. -- ___ Python tracker <http://bugs.python.org/issue20597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20596] Support for alternate wcstok syntax for Windows compilers
Jeffrey Armstrong added the comment: I've replaced the patch with a newer version that defines Py_WCSTOK in Include/pyport.h as Victor suggested. -- Added file: http://bugs.python.org/file34045/wcstok.default.patch ___ Python tracker <http://bugs.python.org/issue20596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20597] PATH_MAX already defined on some Windows compilers
Jeffrey Armstrong added the comment: Here's an additional patch removing PATH_MAX from Modules/main.c and Python/pythonrun.c. This solution works fine for me. -- Added file: http://bugs.python.org/file34044/remove_path_max.default.patch ___ Python tracker <http://bugs.python.org/issue20597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20595] C89 compliance issue in Python/getargs.c
Jeffrey Armstrong added the comment: Depending on your compiler, yes, it is more than a theoretical problem. I am building using the Open Watcom compiler, and it chokes on these initializers due to their non-conformance. I would assume some other obscure, non-GNU/non-MSVC/non-Clang compilers might complain as well. -- ___ Python tracker <http://bugs.python.org/issue20595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20597] PATH_MAX already defined on some Windows compilers
New submission from Jeffrey Armstrong: On some Windows compilers, the constant PATH_MAX may already be defined, which will cause compile errors on non-MSVC compilers (notably Open Watcom and MinGW). Rather than assume it is not available and define it in all "#ifdef MS_WINDOWS" cases, it should first be checked for existence. This patch adds said check to Modules/main.c and Python/pythonrun.c. This patch should not affect any existing platforms (including MSVC builds). -- components: Interpreter Core, Windows files: path_max.default.patch keywords: patch messages: 210936 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: PATH_MAX already defined on some Windows compilers type: compile error versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file34039/path_max.default.patch ___ Python tracker <http://bugs.python.org/issue20597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20596] Support for alternate wcstok syntax for Windows compilers
New submission from Jeffrey Armstrong: In two locations, the current interpreter code makes some assumptions concerning the syntax of the wcstok() function based solely on the operating system (Windows, in this case). Compilers other than MSVC may (and do) provide alternative wcstok() syntaxes. The first change in the attached patch changes a preprocessor check in Modules/main.c to determine if we're compiling with MSVC rather than just whether we're compiling with Windows. If so, it uses Windows's basic two-argument wcstok() function as it always has. If the compiler isn't MSVC, the code will now default to the Unix method of converting to ASCII first before tokenizing. This change is more sensible because the code should really be checking for the compiler's wcstok() capabilities, not what operating system Python is being compiled for. The second change in the attached patch adds some new code to PC/getpathp.c to support alternate wcstok() syntax in the find_env_config_value() function. A preprocessor check will now determine if we're compiling for MSVC and, if so, default to the three-argument wcstok_s() function. If the almost-compatible Open Watcom compiler is detected, a three-argument, POSIX-like wcstok() function is used. If another compiler is detected, the original two-argument wcstok() is assumed to be adequate. -- components: Interpreter Core, Windows files: wcstok.default.patch keywords: patch messages: 210935 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: Support for alternate wcstok syntax for Windows compilers type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file34038/wcstok.default.patch ___ Python tracker <http://bugs.python.org/issue20596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20595] C89 compliance issue in Python/getargs.c
New submission from Jeffrey Armstrong: The file Python/getargs.c currently uses an array initializer with a runtime variable, causing compile errors on strict C89 compilers. The variables named freelist in vgetargs1() and vgetargskeywords() both use non-constant initializers. The attached patch should correct the issue for the default branch. -- components: Interpreter Core files: getargs.c.default.patch keywords: patch messages: 210933 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: C89 compliance issue in Python/getargs.c type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file34037/getargs.c.default.patch ___ Python tracker <http://bugs.python.org/issue20595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20588] Code generated by asdl_c.py not C89-compliant
New submission from Jeffrey Armstrong: The code within Python/Python-ast.c does not currently conform to C89 standard. Within the function PyAST_obj2mod(), the array 'req_type' is initialized using runtime values, which is not allowed by the standard, causing building to fail on a C89 compiler. This code is automatically generated by asdl_c.py. I've attached a patch which corrects the problem. Python/Python-ast.c will need to be regenerated if this patch is accepted. -- components: Interpreter Core files: asdl_c.py.trunk.patch keywords: patch messages: 210894 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: Code generated by asdl_c.py not C89-compliant type: compile error versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file34032/asdl_c.py.trunk.patch ___ Python tracker <http://bugs.python.org/issue20588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19356] Change argument _self in _io/textio.c
Jeffrey Armstrong added the comment: And finally here's the necessary changes to Modules/_elementree.c as well. -- Added file: http://bugs.python.org/file32312/_elementree._self.3.3.2.patch ___ Python tracker <http://bugs.python.org/issue19356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19356] Change argument _self in _io/textio.c
Jeffrey Armstrong added the comment: That was sloppy of me to not check other modules. I hadn't encountered them in my build yet. Here's a patch for Modules/_ctypes/_ctypes.c and Modules/_ctypes/callbacks.c. The arguments were changed similarly to "myself." -- Added file: http://bugs.python.org/file32311/_ctypes._self.3.3.2.patch ___ Python tracker <http://bugs.python.org/issue19356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19356] Change argument _self in _io/textio.c
Changes by Jeffrey Armstrong : -- type: -> compile error ___ Python tracker <http://bugs.python.org/issue19356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19355] Initial modernization of OpenWatcom support
Changes by Jeffrey Armstrong : -- type: -> compile error ___ Python tracker <http://bugs.python.org/issue19355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19356] Change argument _self in _io/textio.c
New submission from Jeffrey Armstrong: At Modules/_io/textio.c:285, one argument to _PyIncrementalNewlineDecoder_decode is named "_self." The name "_self," however is a keyword on older Microsoft C compilers and certain other compilers attempting to maintain compatibility with Microsoft. Renaming the argument to "myself" would fix the problem with certain compilers (Microsoft C, Open Watcom, possibly more). Please note that this is not an issue with MSVC. -- components: Build, IO files: _self.3.3.2.patch keywords: patch messages: 200992 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: Change argument _self in _io/textio.c versions: Python 3.3 Added file: http://bugs.python.org/file32308/_self.3.3.2.patch ___ Python tracker <http://bugs.python.org/issue19356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19355] Initial modernization of OpenWatcom support
New submission from Jeffrey Armstrong: In an attempt to overhaul the existing Open-Watcom-specific portions of CPython, I encountered a number of issues related mostly to preprocessor directives surrounding support for the Open Watcom toolchain on Windows. Specifically, there were a number of places where #defined(MS_WINDOWS) should be checked prior to checking #defined(__WATCOMC__). Additionally, there are some minor differences in the Open Watcom headers from the usual Microsoft headers that lead to problems. Open Watcom, for example, internally defines PATH_MAX, whereas MSVC does not. Open Watcom provides a few additional POSIX-y functions on the Windows platform that, again, MSVC does not. The included patch fixes these minor problems. The changes should not effect compilation with any other compilers. I realize Open Watcom probably isn't directly supported at the moment. I currently have project files, however, that are building CPython with the Open Watcom toolchain with these patches (and a few additional patches - separate issues, though). -- components: Build, Windows files: openwatcom.3.3.2.patch keywords: patch messages: 200991 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: Initial modernization of OpenWatcom support versions: Python 3.3 Added file: http://bugs.python.org/file32307/openwatcom.3.3.2.patch ___ Python tracker <http://bugs.python.org/issue19355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11723] Add support for mingw64 compiler
Changes by Jeffrey Armstrong : -- nosy: +Jeffrey.Armstrong ___ Python tracker <http://bugs.python.org/issue11723> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Jeffrey Armstrong added the comment: > ...the fact that this issue has been open for almost 2 years is quite > ridiculous. I thought that I'd add a little statistic for everyone that might put this bug into perspective. Since this bug was opened, the MinGW installer has been downloaded about 32,000,000 (32 million) times per sf.net: http://sourceforge.net/projects/mingw/files/Installer/stats/timeline?dates=2011-07-26+to+2013-06-23 If we take a naive approach, that's 32 million compiler installations that can't build Python extensions without manually modifying distutils first. That statistic doesn't include the multitude of people installing other builds of GCC for Windows (including MinGW-W64, a whole other unsupported version of GCC, but that's a different bug). -- ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Changes by Jeffrey Armstrong : -- nosy: +Jeffrey.Armstrong ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17391] _cursesmodule Fails to Build on GCC 2.95 (static)
Changes by Jeffrey Armstrong : -- components: +Extension Modules -Build ___ Python tracker <http://bugs.python.org/issue17391> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17391] _cursesmodule Fails to Build on GCC 2.95 (static)
New submission from Jeffrey Armstrong: When compiling Modules/_cursesmodule.c as a static module with GCC 2.95.3, an error is encountered on line 2260 in PyCurses_GetWin. The error occurs because the PyCursesInitialised macro appears prior _Py_IDENTIFIER(read), which is actually a variable declaration. Switching the order of the statements fixes the issue. In all other functions within Modules/_cursesmodule.c, PyCursesInitialised always appears after all variable declarations. This bug was encountered on the platform m68k-atari-mint using Python 3.3.0 and GCC 2.95.3. -- components: Build files: curses.patch keywords: patch messages: 183877 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: _cursesmodule Fails to Build on GCC 2.95 (static) type: compile error versions: Python 3.3 Added file: http://bugs.python.org/file29365/curses.patch ___ Python tracker <http://bugs.python.org/issue17391> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17226] libintl should also check for libiconv
Jeffrey Armstrong added the comment: I would suggest a more straightforward patch. My understanding is that the standard library on the m68k-atari-mint platform does not include the necessary gettext functionality. This functionality is present in glibc, however. A more direct test might be to see if gettext is available in the standard library. If so, proceed. If not, attempt to link in libintl and its dependency: --- a/configure.ac Sat Feb 23 18:52:51 2013 +0100 +++ b/configure.ac Sun Feb 24 17:59:41 2013 -0500 @@ -2180,6 +2180,14 @@ [Define to 1 if libintl is needed for locale functions.]) LIBS="-lintl $LIBS"]) +# search for gettext in either libc or libintl +AC_CHECK_FUNC(gettext, [], + [AC_CHECK_LIB(intl, gettext, + [LIBS="$LIBS -lintl -liconv"], + [AC_MSG_ERROR([unable to find the gettext() function])], + [-liconv]) +]) + -- ___ Python tracker <http://bugs.python.org/issue17226> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17226] libintl should also check for libiconv
Jeffrey Armstrong added the comment: Alan, I was about to file a bug as well because I'm not even getting a libintl dependency to be acknowledged under these build conditions. What versions of gettext and GCC are you using? Ned, not sure if it matters, but the libintl page does specify that -liconv must also be linked as it is a dependency: http://www.gnu.org/software/gettext/FAQ.html#integrating_undefined -- nosy: +Jeffrey.Armstrong ___ Python tracker <http://bugs.python.org/issue17226> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16880] Importing "imp" will fail if dynamic loading not supported
Jeffrey Armstrong added the comment: Sorry, I think my question was a bit vague. Christian's patch does, in fact, work fine for fixing the problem as reported. I was wondering if the patch was sufficient to close the bug with a commit. I didn't know if other work was ongoing to close this issue. -- ___ Python tracker <http://bugs.python.org/issue16880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16880] Importing "imp" will fail if dynamic loading not supported
Jeffrey Armstrong added the comment: Is Christian's patch going to be sufficient for the time being? Just curious. -- ___ Python tracker <http://bugs.python.org/issue16880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16953] select module compile errors with broken poll()
Jeffrey Armstrong added the comment: I've attached the patch, and I probably should have done so in the first place. It applies to Python 3.3.0. The resulting code compiles fine on m68k-atari-mint. It shouldn't affect any of the major platforms. -- Added file: http://bugs.python.org/file28779/select_module_patch.txt ___ Python tracker <http://bugs.python.org/issue16953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16953] select module compile errors with broken poll()
Changes by Jeffrey Armstrong : -- type: -> compile error ___ Python tracker <http://bugs.python.org/issue16953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16953] select module compile errors with broken poll()
New submission from Jeffrey Armstrong: On a platform with a broken poll() function (as detected during configure), Modules/selectmodule.c fails to compile. The error occurs at two points: ./Modules/selectmodule.c:2100: `select_poll' undeclared here (not in a function) ./Modules/selectmodule.c:2100: initializer element is not constant ./Modules/selectmodule.c:2100: (near initialization for `select_methods[1].ml_meth') ./Modules/selectmodule.c:2100: `poll_doc' undeclared here (not in a function) ./Modules/selectmodule.c:2100: initializer element is not constant ./Modules/selectmodule.c:2100: (near initialization for `select_methods[1].ml_doc') ./Modules/selectmodule.c: In function `PyInit_select': ./Modules/selectmodule.c:2159: `poll_Type' undeclared (first use in this function) ./Modules/selectmodule.c:2159: (Each undeclared identifier is reported only once ./Modules/selectmodule.c:2159: for each function it appears in.) The problem is occurring because both "select_poll" and "poll_Type" are undeclared if HAVE_BROKEN_POLL is declared. The fix would be on two lines: selectmodule.c:2099 #ifdef(HAVE_POLL) should be: #if defined(HAVE_POLL) && !defined(HAVE_BROKEN_POLL) selectmodule.c:2149 #if defined(HAVE_POLL) should be: #if defined(HAVE_POLL) && !defined(HAVE_BROKEN_POLL) Making these two minor changes allows selectmodule.c to compile fine in the case where the platform has a "broken" poll(). This bug was found on m68k-atari-mint compiling using gcc 2.95.3 -- components: Build messages: 179880 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: select module compile errors with broken poll() versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue16953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16880] Importing "imp" will fail if dynamic loading not supported
Jeffrey Armstrong added the comment: Terry: If I'm understanding this correctly, C_EXTENSION implies a dynamically loaded module authored in C. The issue on FreeMiNT, the operating system in question, is that there is no support for true shared objects. Any C modules must be statically linked with the Python executable. I'm thinking the answer is "No, it won't be a problem on m68k-atari-mint," if I'm understanding the meaning of "C_EXTENSION" correctly. -- ___ Python tracker <http://bugs.python.org/issue16880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16880] Importing "imp" will fail if dynamic loading not supported
Jeffrey Armstrong added the comment: The patch works with respect to allowing the interpreter to start, and importing modules from the interpreter seems to be working fine. I can't speak to Brett's concerns about possible side effects of setting load_dynamic to None. -- ___ Python tracker <http://bugs.python.org/issue16880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16881] Py_ARRAY_LENGTH macro incorrect with GCC < 3.1
New submission from Jeffrey Armstrong: The Py_ARRAY_LENGTH macro (Include/pymacro.h:36) checks to see if using GCC by simply looking for __GCC__ being defined. If so, it uses the GCC extension function "__builtin_types_compatible_p." However, this function was not introduced until GCC 3.1. This simple check for a GCC compiler causes the Python build to fail on GCC < 3.1 (2.95 for example). The check should actually be: #if (defined(__GNUC__) && !defined(__STRICT_ANSI__) && \ ((__GNUC__ == 3) && (__GNU_MINOR__) >= 1) || (__GNUC__ >= 4))) Similar checks are made in other locations in the core library, just not here. This bug was discovered while attempting a build on m68k-atari-mint, which relies on GCC 2.95.3. Other systems may also be using this compiler still. -- components: Build messages: 179187 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: Py_ARRAY_LENGTH macro incorrect with GCC < 3.1 type: compile error versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue16881> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16880] Importing "imp" will fail if dynamic loading not supported
New submission from Jeffrey Armstrong: On a platform where dynamic loading is unsupported, the function "imp_load_dynamic" is not compiled (Python/import.c:1775), and the Python function "load_dynamic" (Python/import.c:1845) will not be included in the _imp module. However, Lib/imp.py attempts to import "load_dynamic" from _imp (Lib/imp.py:9), causing an ImportError if dynamic loading is unsupported. The interpreter is unable to start under these circumstances. The error was encountered on m68k-atari-mint using GCC as the compiler. This platform is a desktop environment, but has no support for true shared objects and libraries. -- components: Library (Lib) messages: 179186 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: Importing "imp" will fail if dynamic loading not supported type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue16880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
