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'
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
Change by Erik Janssens :
--
pull_requests: +13401
___
Python tracker
<https://bugs.python.org/issue36965>
___
___
Python-bugs-list mailing list
Unsubscribe:
Erik Janssens added the comment:
PR has been changed to include "windows.h" ...
--
___
Python tracker
<https://bugs.python.org/issue36965>
___
___
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/is
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 ??
--
__
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
Change by Erik Janssens :
--
keywords: +patch
pull_requests: +13330
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36965>
___
___
Py
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
Erik Janssens added the comment:
The same issue was handled in bpo-35890
--
pull_requests: +13329
___
Python tracker
<https://bugs.python.org/issue20
Change by Erik Janssens :
--
pull_requests: +13328
___
Python tracker
<https://bugs.python.org/issue35890>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<ht
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
Change by Erik Janssens :
--
pull_requests: +9597
___
Python tracker
<https://bugs.python.org/issue20596>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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 iss
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 s
Change by Erik Janssens :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue34217>
___
___
Pyth
Change by Erik Janssens :
--
keywords: +patch
pull_requests: +8526
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34581>
___
___
Py
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
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 ab
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
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/issue34
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
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: ht
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/is
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 ne
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/issue20
Change by Erik Janssens :
--
pull_requests: +8058
___
Python tracker
<https://bugs.python.org/issue34217>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Erik Janssens :
--
keywords: +patch
pull_requests: +7978
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34217>
___
___
Py
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
31 matches
Mail list logo
