This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Add Mingw recognition to pyport.h to allow building extensions
Type: Stage: resolved
Components: Build, Windows Versions: Python 3.10, Python 3.9, Python 3.8
process
Status: closed Resolution: wont fix
Dependencies: Superseder: MinGW is unsupported - close all open issues and list them here.
View: 45538
Assigned To: Nosy List: brian.curtin, eric.araujo, f0k, jlt63, rpetrov, stutzbach
Priority: normal Keywords: patch

Created on 2009-08-09 12:24 by f0k, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
pyport-issue6672.diff f0k, 2009-10-20 12:00 Patch to pyport.h of Python 2.6 or 2.7 to handle Mingw correctly review
0002-MINGW-issue6672-add-mingw-recognition-to-pyport.h-to.patch rpetrov, 2013-02-02 17:52 issue3871 split : pyport.h for extentions module build with gcc(mingw*)
0003-issue6672-v2-Add-Mingw-recognition-to-pyport.h-to-al.patch rpetrov, 2013-07-17 20:26 v2 with defined Py_BUILD_CORE_MODULE
Messages (6)
msg91427 - (view) Author: Jan Schlüter (f0k) Date: 2009-08-09 12:24
This addresses missing statements for recognizing the Mingw compiler in 
pyport.h, needed to build several extension modules on Windows using 
Mingw. I will first explain the background, then indicate what needs to 
be changed and end with some pointers to "related work".

Pyport.h of Python 2.5 and 2.6 (I do not have other versions to check) 
addresses an issue with Cygwin's gcc by preventing the declaration of 
"__declspec(dllimport)" for function definitions (using the PyAPI_FUNC
(RTYPE) makro), relying on the compiler's auto-import definition 
instead, because the compiler would not otherwise throw an "initializer 
element is not constant" error when using e.g. PyObject_GenericGetAttr 
in a PyTypeObject declaration of a C/C++ extension module (more 
generally, whenever an imported Python API function is used as a 
constant).
Python 2.6.2 (r262:71605) and Python 2.5.4 (r254:67916) do not check 
for the Mingw compiler in pyport.h, although Mingw behaves the same as 
the Cygwin version, at least regarding the "__declspec" declaration.

To fix that, each check for __CYGWIN__ in pyport.h should also check 
for __MINGW32___ to behave the same way. svn.python.org currently does 
not reply, so I can not create a patch against the trunk nor check 
whether this issue has already been addressed.

Issue 5046 included a patch to pyport.h fixing this, but it has been 
rejected due to other suggested changes that were not mature.
http://recipes.gobolinux.org/r/?list=Python&ver=3.1-
r1&file=arm/20061116160247-
bf48b-7db78fe2f80b3137ce349cf4314364768555ff50.gz.diff suggests the 
same change.
http://www.indashpc.org/vbullettin/viewtopic.php?p=5003#5003 gives some 
more background information on how I found and fixed the problem.
An internet search for "python initializer element is not constant" 
shows that numerous people have been encountering this problem when 
trying to build a python extension module.
msg94259 - (view) Author: Daniel Stutzbach (stutzbach) (Python committer) Date: 2009-10-19 19:50
svn.python.org seems to be up again.  Could you create a patch?
msg94273 - (view) Author: Jan Schlüter (f0k) Date: 2009-10-20 12:00
Hello!

Thanks, you're right. I have created a patch against the latest SVN 
revision (75557) of branches/release26-maint/Include/pyport.h. The 
patch also applies fine to trunk/Include/pyport.h.
As it applies to both versions, I have created the patch directly from 
inside the Include directory rather than from the svn root.

As I am abroad for a couple of months and do not have access to my 
Windows machine, I currently cannot test the patch (i.e. compile Python 
on Windows using Mingw), but I successfully compiled the PyMedia 
package using Mingw and the modified pyport.h.

Please let me know if you have any questions or remarks!
msg116137 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-09-12 00:12
A tip about versions: Bugs are fixed on the active branch, py3k (which will become 3.2), then backported to 3.1 and 2.7.  Security fixes go into 2.5 and 2.6 too.
msg181187 - (view) Author: Roumen Petrov (rpetrov) * Date: 2013-02-02 17:52
Version against current (2013-02-02) source.
msg193247 - (view) Author: Roumen Petrov (rpetrov) * Date: 2013-07-17 20:26
new patch - improved version with support for build of core modules
History
Date User Action Args
2022-04-11 14:56:51adminsetgithub: 50921
2021-10-21 10:03:53iritkatrielsetresolution: duplicate -> wont fix
2021-10-20 12:55:11iritkatrielsetstatus: open -> closed
superseder: MinGW is unsupported - close all open issues and list them here.
resolution: duplicate
stage: patch review -> resolved
2020-11-11 19:00:13iritkatrielsetversions: + Python 3.8, Python 3.9, Python 3.10, - Python 2.7, Python 3.2, Python 3.4
2014-04-03 19:11:39ned.deilyunlinkissue21124 superseder
2014-04-02 01:23:30ned.deilylinkissue21124 superseder
2013-10-24 10:00:15tim.goldensetnosy: - tim.golden
2013-07-17 20:26:37rpetrovsetfiles: + 0003-issue6672-v2-Add-Mingw-recognition-to-pyport.h-to-al.patch

messages: + msg193247
2013-02-02 17:52:01rpetrovsetfiles: + 0002-MINGW-issue6672-add-mingw-recognition-to-pyport.h-to.patch

messages: + msg181187
versions: + Python 3.4
2010-09-12 00:12:37eric.araujosetnosy: + jlt63, tim.golden, brian.curtin, eric.araujo
messages: + msg116137
2010-08-04 05:07:03terry.reedysetversions: + Python 3.2, - Python 2.6, Python 2.5
2010-04-27 15:24:40stutzbachsetnosy: stutzbach, rpetrov, f0k
components: + Windows
stage: patch review
2009-10-21 21:38:35rpetrovsetnosy: + rpetrov
2009-10-20 12:00:25f0ksetfiles: + pyport-issue6672.diff
keywords: + patch
messages: + msg94273

versions: + Python 2.7
2009-10-19 19:50:05stutzbachsetmessages: + msg94259
2009-10-19 19:48:35stutzbachsetnosy: + stutzbach
2009-08-09 12:24:49f0kcreate