[issue34553] Python Crashes when trying to access any date related fields in MailItem
Erik Janssens added the comment: At least for us, the issue seems to be related to the MSVC runtime. We compiled python with mingw using the mingw runtime, and the issue was gone. On Tue, 2021-10-19 at 09:02 +, Irit Katriel wrote: > Irit Katriel added the comment: > It doesn't look like there's anything we can do here on the python > side. > If nobody will object I will close this ticket. > --nosy: +iritkatrielstatus: open -> pending > ___Python tracker > < > https://bugs.python.org/issue34553>___ -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue34553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37801] Compilation on MINGW64 fails (CODESET,wcstok,...)
Erik Janssens added the comment: fyi 1 : this issue pops up in multiple places, cfr : * bpo-35890 * bpo-20596 the selection of the wcstok function is based on MS_WINDOWS being defined, rather than eg. an autoconf check on which function is available. fyi 2 : I've been able to cross compile 3.8 with mingw64 (gcc 7.3), but with a custom meson script instead of autoconf -- nosy: +erikjanss ___ Python tracker <https://bugs.python.org/issue37801> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers
Change by Erik Janssens : -- pull_requests: +13401 ___ Python tracker <https://bugs.python.org/issue36965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers
Erik Janssens added the comment: PR has been changed to include "windows.h" ... -- ___ Python tracker <https://bugs.python.org/issue36965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers
Erik Janssens added the comment: ok, thank you for the advice, I'll keep it in mind and adapt the PR ! -- ___ Python tracker <https://bugs.python.org/issue36965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers
Erik Janssens added the comment: including "winnt.h" gives me compilation problems with other undefined types. however, simply including "windows.h" instead of both includes compiles just fine. so maybe that is sufficient ?? -- ___ Python tracker <https://bugs.python.org/issue36965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers
Erik Janssens added the comment: According to the Microsoft documentation at https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/using-ntstatus-values system-supplied status codes are defined in ntstatus.h. and the NTSTATUS type is defined in ntdef.h PR 13421 includes both ntstatus.h and ntdef.h to be able to use STATUS_CONTROL_C_EXIT when compiling for windows. -- ___ Python tracker <https://bugs.python.org/issue36965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers
Change by Erik Janssens : -- keywords: +patch pull_requests: +13330 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers
New submission from Erik Janssens : in Modules/main.c STATUS_CONTROL_C_EXIT is included conditionally if compiling when _MSC_VER is defined. Later on STATUS_CONTROL_C_EXIT is used if MS_WINDOWS is defined. This breaks compilation of main.c with any non MSC compiler while compiling for MS Windows. This appears to have been introduced in GH-12123 for bpo-36142 -- components: Windows messages: 342845 nosy: erikjanss, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers type: compile error versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36965> ___ ___ 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
Erik Janssens added the comment: The same issue was handled in bpo-35890 -- pull_requests: +13329 ___ 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
[issue35890] Cleanup some non-consistent API callings
Change by Erik Janssens : -- pull_requests: +13328 ___ Python tracker <https://bugs.python.org/issue35890> ___ ___ 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
Erik Janssens added the comment: @serhiy.storchaka Are you suggesting the discrimination should be based on compiler specific defines, or rather that it should go through configuration (a HAVE_WCSTOK_S pyconfig.h) ? -- ___ 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
[issue20596] Support for alternate wcstok syntax for Windows compilers
Erik Janssens added the comment: I created a github pull request based on the last patch of Jeffrey Armstrong. Since mingw now also has a wcstok_s function, the discrimination between wcstok/wcstok_s is now based on MS_WINDOWS being defined, as was the case in Modules/main.c. Is this correct, or should it be based on the detected compiler ? -- ___ 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
[issue20596] Support for alternate wcstok syntax for Windows compilers
Change by Erik Janssens : -- pull_requests: +9597 ___ 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
[issue34553] Python Crashes when trying to access any date related fields in MailItem
Erik Janssens added the comment: @vijay may I suggest you try to investigate your issue in more detail : - does it depend on the Python version ? If so which versions work, which dont. - does the crash happen as well when using the REPL ? - if you use PyQt instead of pywin32, does it still crash ? Not that any of these suggestions will lead to a clear solution, but it might at least rule out some things. -- ___ Python tracker <https://bugs.python.org/issue34553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34553] Python Crashes when trying to access any date related fields in MailItem
Erik Janssens added the comment: @ronaldoussoren In my case it was not Outlook, it was a third party line of business application, but as in the case of the OP, as mentioned in the StackOverflow link, the crashing only happens using certain Python version. I'm not suggesting the issue of the OP (nor mine) is in CPython. But it's strange at least that it depends on the Python version, and that it does not crash when using the REPL (I did try to compensate for delays etc.). I took the PyQt route to 'proof' the issue is not related to pywin32. When running it in a debugger, the crash happens in an MFC dll, after the Invoke of the COM method. So my guess is the issue is related to some incompatibility in MSVC libraries between CPython and the line of business application. -- ___ Python tracker <https://bugs.python.org/issue34553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34553] Python Crashes when trying to access any date related fields in MailItem
Erik Janssens added the comment: for what's it worth, I've observed similar crashes under these strange circumstances : - the crashes don't appear in python 3.4, but they do in 3.5 (maybe due to switch in msvc runtime) - the crashes do appear when run as script, the exact same commands in the repl work as expected - the crashes behave the same when using ActiveQt/PyQt instead of pywin32, which suggests it's not a pywin32 issue -- nosy: +erikjanss ___ Python tracker <https://bugs.python.org/issue34553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34217] windows: cross compilation fails due to headers with uppercase
Change by Erik Janssens : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34581] Windows : use of __pragma msvc extension without ifdef
Change by Erik Janssens : -- keywords: +patch pull_requests: +8526 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34581] Windows : use of __pragma msvc extension without ifdef
New submission from Erik Janssens : The socketmodule uses the MSVC extension __pragma. The use of this extension is not enabled/disable by an #ifdef _MSC_VER. This prevents compilation with other compilers then MSVC on Windows. -- components: Extension Modules messages: 324603 nosy: erikjanss priority: normal severity: normal status: open title: Windows : use of __pragma msvc extension without ifdef type: compile error versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34217] windows: cross compilation fails due to headers with uppercase
Erik Janssens added the comment: I'll try to be more precise : - I did an (imperfect) search : before these changes 98% of the windows headers were included in the .c files in lowercase - These changes would bring it to 100% - The advantage of these changes are consistency and the ability to cross compile those .c files on linux for a windows target, using the mingw-w64 sdk, where the sdk is on a case sensitive filesystem, as is the default when installing this sdk in most linux distributions. - I did not consider, nor did I test other toolchains than mingw-w64/mingw-w64-sdk on linux and msvc/windows-sdk on windows. I'm not enough of an expert on the different tools to come up with a comprehensive solution for this issue, but am willing to validate such solution for the use case of cross compiling on linux. -- ___ Python tracker <https://bugs.python.org/issue34217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34217] windows: cross compilation fails due to headers with uppercase
Erik Janssens added the comment: As I understand it, if mingw-w64 would change to camelcase headers, it would break backwards compatibility, since a lot of windows source code uses file names in includes that differ from those on this, which works in MSVC, so it goes unnoticed. There is no good solution. Even if camelcase headers would be available, the CPython source code would break in much more places. I agree that it would be strange to have a style rule for a specific toolset, however mixing different styles is even stranger. The current situation is that 100% of the windows includes are lowercase and allow cross compilation. I would tend to see that as an advantage. If a more comprehensive solution would be available, that would be ideal of course. -- ___ Python tracker <https://bugs.python.org/issue34217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34217] windows: cross compilation fails due to headers with uppercase
Erik Janssens added the comment: The lowercase headers are indeed part of the mingw-w64 SDK, which is the most convenient option to cross compile on a linux host for a windows target. -- ___ Python tracker <https://bugs.python.org/issue34217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34217] windows: cross compilation fails due to headers with uppercase
Erik Janssens added the comment: @inada.naoki : thank you ! @steve.dower : I would not consider those bugs per se, but they are inconsistencies, for example in the master branch : number of "Windows.h" includes : 2 number of "windows.h" includes : 55 whatever might be the 'right' solution, it's always an advantage to have a consistent codebase. -- ___ Python tracker <https://bugs.python.org/issue34217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34217] windows: cross compilation fails due to headers with uppercase
Erik Janssens added the comment: Attached a small helper script to detect camelcase windows headers, 2 more occurences found : Modules/socketmodule.c versionhelpers.h 306 #include Tools/msi/bundle/bootstrap/pch.h uxtheme.h 18 #include -- status: closed -> open Added file: https://bugs.python.org/file47751/windows_headers.py ___ Python tracker <https://bugs.python.org/issue34217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27186] add os.fspath()
Erik Janssens added the comment: thank you for the info ... I'll have a look at making the posix module easier to port ... -- ___ Python tracker <https://bugs.python.org/issue27186> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27186] add os.fspath()
Erik Janssens added the comment: is there a particular reason for PyOS_FSPath to live in posixmodule.c since Objects/unicodeobject.c uses this function, this makes it not possible to compile Python without a posixmodule. this makes it difficult to compile a 'core' python on a new platform, since implementing the posixmodule on a new platform is not trivial. also the documentation on porting mentions that one should first port python without a posixmodule. -- nosy: +erikjanss ___ Python tracker <https://bugs.python.org/issue27186> ___ ___ 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
Erik Janssens added the comment: Would anyone mind if I create a new issue to reflect the current situation and create a PR to handle it with a Py_WCSTOK ? -- nosy: +erikjanss ___ 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
[issue34217] windows: cross compilation fails due to headers with uppercase
Change by Erik Janssens : -- pull_requests: +8058 ___ Python tracker <https://bugs.python.org/issue34217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34217] windows: cross compilation fails due to headers with uppercase
Change by Erik Janssens : -- keywords: +patch pull_requests: +7978 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34217] windows: cross compilation fails due to headers with uppercase
New submission from Erik Janssens : When cross compiling python on a linux host with a case sensitive file system for a windows target. The compilation will fail due to header files which contain uppercases. -- components: Cross-Build, Windows messages: 322333 nosy: Alex.Willmer, erikjanss, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: windows: cross compilation fails due to headers with uppercase type: compile error versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
