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: Trivial mingw compile fixes
Type: compile error Stage: resolved
Components: Build 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: amaury.forgeotdarc, eric.araujo, jonny, loewis, rpetrov, schmir
Priority: normal Keywords: patch

Created on 2010-12-03 12:45 by jonny, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
Python-3.1.3.fix_mingw_compile.diff jonny, 2010-12-03 12:45
pyconfig.h jonny, 2010-12-06 12:22
Messages (22)
msg123236 - (view) Author: Johann Hanne (jonny) Date: 2010-12-03 12:45
Some C files fail to compile with mingw, mostly due to missing preprocessor statements:
- Modules/_ctypes/callproc.c
When using the bundled non-msvc libffi, ffi_call has no return value, so only use it when compiled with msvc.
- Modules/_pickle.c
There are Windows data types FLOAT, INT, LONG which the pickle code conflicts with.
- Modules/posixmodule.c
Some "#ifdef _MSC_VER" paragraphs apply for __MINGW32__ as well; for MinGW, wincrypt.h must be explicitely included (the "original" Windows headers include them in windows.h)
- Modules/signalmodule.c
On case-sensitive filesystems, windows.h must be all-lowercase
- Modules/socketmodule.h
MinGW does not define SIO_KEEPALIVE_VALS, so do it here if required
- PC/msvcrtmodule.c
MinGW does not have crtdbg.h
- PC/winreg.c
MinGW does not define REG_LEGAL_CHANGE_FILTER, so do it here if required
- Python/dynload_win.c
strcasecmp is already defined with MinGW, so use a private name
- Python/pythonrun.c
MinGW has locale.h, but not langinfo.h

This patch fixes all the mentioned problems.
msg123302 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-12-03 22:40
When the patch is applied, what's the resulting status of mingw compilation?
msg123318 - (view) Author: Johann Hanne (jonny) Date: 2010-12-04 08:32
>When the patch is applied, what's the resulting status of mingw compilation?

It compiles all C files which I require. Not sure if this is really *all* C files, but at least very close to all. I will post a list of object files I get on Monday.
msg123320 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-12-04 08:44
Am 04.12.2010 09:32, schrieb Johann Hanne:
> 
> Johann Hanne <python@jf.hanne.name> added the comment:
> 
>> When the patch is applied, what's the resulting status of mingw compilation?
> 
> It compiles all C files which I require. Not sure if this is really *all* C files, but at least very close to all. I will post a list of object files I get on Monday.

Will it then also link something?
msg123386 - (view) Author: Johann Hanne (jonny) Date: 2010-12-04 19:26
>Will it then also link something?

Sure - it actually builds a python.exe which is fully working for me. If you need a proof, please let me know, I have no problem uploading it somewhere...

Is there a reason you are so sceptical? After all, Python for Linux is also usually compiled with gcc, so why shouldn't it work for Win32?
msg123391 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-12-04 19:47
> Sure - it actually builds a python.exe which is fully working for me. If you need a proof, please let me know, I have no problem uploading it somewhere...
> 
> Is there a reason you are so sceptical? After all, Python for Linux is also usually compiled with gcc, so why shouldn't it work for Win32?

There is a long track of people contributing patches to Python saying
"you need this and that to make it work on platform XYZ". Right after
accepting these patches (without testing, because we might not have
access to XYZ) they come back with more patches. If you then look
carefully at the initial submission, they never actually claimed that
this is *all* patches that are needed. Instead, they use phrases like
"some trivial fixes" (meaning that the difficult fixes are yet to come).
msg123396 - (view) Author: Johann Hanne (jonny) Date: 2010-12-04 20:03
Ok, I see. And no, this is *not* my intention. I will post the list of successfully compiled objects files and the linker result on Monday as promised. If it turns out I lied, feel free to put me into the hall of shame.

After all, the Win32 platform is not that uncommon. I know, MinGW could be seen as a different platform, but I never encountered a situation where I required anything but the exe file (no special MinGW DLL or something like that).
msg123397 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-12-04 20:06
> After all, the Win32 platform is not that uncommon. I know, MinGW
> could be seen as a different platform, but I never encountered a
> situation where I required anything but the exe file (no special
> MinGW DLL or something like that).

Traditionally, MingW-compiled Python binaries would often be
binary-incompatible with the ones available from python.org, since the
MingW build would use a different version of the MS CRT than the
python.org version. As a consequence, extensions built for the official
binaries would crash in the MingW build, and vice versa.
msg123404 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2010-12-04 21:04
> As a consequence, extensions built for the official
> binaries would crash in the MingW build, and vice versa

IMO this is a use case for the new "soabi" tag...
msg123405 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2010-12-04 21:23
> Sure - it actually builds a python.exe which is fully working for me.
> If you need a proof, please let me know, I have no problem uploading
> it somewhere...

This is useless, of course.  The build must be reproducible.
Here is what I did so far:

- Open a cmd.exe console, ensure that msys/bin and mingw/bin are in the PATH
- Run "sh configure" - it's slow, but works.
- Run "make"
- Re-running "make -k" fails on three files: import.c, posixmodule.c, and pwdmodule.c

Your patch does not touch import.c, and the pwd module should probably be removed from a Python running on Windows.
Do you use another method to compile Python?
msg123407 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-12-04 22:59
> IMO this is a use case for the new "soabi" tag...

Unfortunately not: these tags are not supported on Windows.
msg123409 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2010-12-04 23:34
> > IMO this is a use case for the new "soabi" tag...
> Unfortunately not: these tags are not supported on Windows.
So it's a argument for adding (optional?) soabi tags on Windows!
msg123463 - (view) Author: Johann Hanne (jonny) Date: 2010-12-06 12:22
> Traditionally, MingW-compiled Python binaries would often be
binary-incompatible

I don't plan to distribute a MinGW compiled package as an alternative to the official MSVC based build. In my particular use case, I compile everything into a single exe and put the Lib/*.py files into a single zip file. The result is a two-file Python distribution which doesn't need an installation. If somebody is interested, I can elaborate, but this would be off-topic here.

As for the reproducibility issue: The configure/Makefile system coming with Python simply doesn't support creating a Windows build. I hope it's clear that the patch is NOT about creating a Windows installer. If this is a requirement for getting my patch in, please let me know so I can stop wasting my time!

Whatsoever, if you simply want to reproduce that my compile (!) fixes work, please follow these steps:
- Start a MinGW shell and cd into the Python source tree
- CFLAGS="-IPC -IPython" ./configure
- Remove the created pyconfig.h and replace PC/pyconfig.h with the manually modified version I'm attaching
- Modify the Makefile:
-- Remove pwdmodule.c from the MODOBJS variable
-- Add to the MODOBJS variable: PC/dl_nt.o PC/import_nt.o
-- Remove the LIBOBJS variable assigment
-- Edit the "# Build the interpreter" paragraph: Add PC/empty.o to the rule dependencies *AND* after "...$(SYSLIBS) $(LDLAST)"
- Modify PC/empty.c: Add "#include "Python.h" as first line; replace 'return 0;' by 'wchar_t *wargv[] = { L"python.exe", NULL }; return Py_Main(1, wargv);'
- Run make
- Add the the full path to the Lib directory to your PYTHONPATH
msg123464 - (view) Author: Johann Hanne (jonny) Date: 2010-12-06 12:32
As promised, here comes the list of modules which successfully compile with MinGW:


./Python-3.1.3/PC/import_nt.o
./Python-3.1.3/PC/_subprocess.o
./Python-3.1.3/PC/dl_nt.o
./Python-3.1.3/PC/msvcrtmodule.o
./Python-3.1.3/PC/winreg.o
./Python-3.1.3/Parser/pgen.o
./Python-3.1.3/Parser/grammar1.o
./Python-3.1.3/Parser/parser.o
./Python-3.1.3/Parser/listnode.o
./Python-3.1.3/Parser/parsetok.o
./Python-3.1.3/Parser/tokenizer.o
./Python-3.1.3/Parser/printgrammar.o
./Python-3.1.3/Parser/myreadline.o
./Python-3.1.3/Parser/firstsets.o
./Python-3.1.3/Parser/metagrammar.o
./Python-3.1.3/Parser/grammar.o
./Python-3.1.3/Parser/acceler.o
./Python-3.1.3/Parser/node.o
./Python-3.1.3/Parser/bitset.o
./Python-3.1.3/Python/getcompiler.o
./Python-3.1.3/Python/codecs.o
./Python-3.1.3/Python/pystrtod.o
./Python-3.1.3/Python/pyfpe.o
./Python-3.1.3/Python/getargs.o
./Python-3.1.3/Python/modsupport.o
./Python-3.1.3/Python/getopt.o
./Python-3.1.3/Python/formatter_unicode.o
./Python-3.1.3/Python/mysnprintf.o
./Python-3.1.3/Python/pyctype.o
./Python-3.1.3/Python/sysmodule.o
./Python-3.1.3/Python/errors.o
./Python-3.1.3/Python/pymath.o
./Python-3.1.3/Python/pythonrun.o
./Python-3.1.3/Python/pystrcmp.o
./Python-3.1.3/Python/pystate.o
./Python-3.1.3/Python/getversion.o
./Python-3.1.3/Python/_warnings.o
./Python-3.1.3/Python/Python-ast.o
./Python-3.1.3/Python/frozen.o
./Python-3.1.3/Python/getcopyright.o
./Python-3.1.3/Python/asdl.o
./Python-3.1.3/Python/pyarena.o
./Python-3.1.3/Python/importdl.o
./Python-3.1.3/Python/compile.o
./Python-3.1.3/Python/dtoa.o
./Python-3.1.3/Python/getplatform.o
./Python-3.1.3/Python/traceback.o
./Python-3.1.3/Python/ceval.o
./Python-3.1.3/Python/mystrtoul.o
./Python-3.1.3/Python/thread.o
./Python-3.1.3/Python/symtable.o
./Python-3.1.3/Python/structmember.o
./Python-3.1.3/Python/future.o
./Python-3.1.3/Python/graminit.o
./Python-3.1.3/Python/peephole.o
./Python-3.1.3/Python/marshal.o
./Python-3.1.3/Python/import.o
./Python-3.1.3/Python/bltinmodule.o
./Python-3.1.3/Python/dynload_win.o
./Python-3.1.3/Python/ast.o
./Python-3.1.3/Modules/sha512module.o
./Python-3.1.3/Modules/socketmodule.o
./Python-3.1.3/Modules/expat/xmltok.o
./Python-3.1.3/Modules/expat/xmlrole.o
./Python-3.1.3/Modules/expat/xmlparse.o
./Python-3.1.3/Modules/_csv.o
./Python-3.1.3/Modules/_randommodule.o
./Python-3.1.3/Modules/errnomodule.o
./Python-3.1.3/Modules/_weakref.o
./Python-3.1.3/Modules/arraymodule.o
./Python-3.1.3/Modules/symtablemodule.o
./Python-3.1.3/Modules/zipimport.o
./Python-3.1.3/Modules/sha256module.o
./Python-3.1.3/Modules/mmapmodule.o
./Python-3.1.3/Modules/_ctypes/_ctypes_test.o
./Python-3.1.3/Modules/_ctypes/libffi/src/prep_cif.o
./Python-3.1.3/Modules/_ctypes/libffi/src/x86/ffi.o
./Python-3.1.3/Modules/_ctypes/libffi/src/x86/win32.o
./Python-3.1.3/Modules/_ctypes/callbacks.o
./Python-3.1.3/Modules/_ctypes/stgdict.o
./Python-3.1.3/Modules/_ctypes/_ctypes.o
./Python-3.1.3/Modules/_ctypes/callproc.o
./Python-3.1.3/Modules/_ctypes/malloc_closure.o
./Python-3.1.3/Modules/_ctypes/cfield.o
./Python-3.1.3/Modules/operator.o
./Python-3.1.3/Modules/posixmodule.o
./Python-3.1.3/Modules/md5module.o
./Python-3.1.3/Modules/timemodule.o
./Python-3.1.3/Modules/_functoolsmodule.o
./Python-3.1.3/Modules/datetimemodule.o
./Python-3.1.3/Modules/cmathmodule.o
./Python-3.1.3/Modules/zlibmodule.o
./Python-3.1.3/Modules/_threadmodule.o
./Python-3.1.3/Modules/itertoolsmodule.o
./Python-3.1.3/Modules/_lsprof.o
./Python-3.1.3/Modules/_tkinter.o
./Python-3.1.3/Modules/getbuildinfo.o
./Python-3.1.3/Modules/_collectionsmodule.o
./Python-3.1.3/Modules/_localemodule.o
./Python-3.1.3/Modules/_io/iobase.o
./Python-3.1.3/Modules/_io/bytesio.o
./Python-3.1.3/Modules/_io/stringio.o
./Python-3.1.3/Modules/_io/_iomodule.o
./Python-3.1.3/Modules/_io/textio.o
./Python-3.1.3/Modules/_io/bufferedio.o
./Python-3.1.3/Modules/_io/fileio.o
./Python-3.1.3/Modules/_struct.o
./Python-3.1.3/Modules/_codecsmodule.o
./Python-3.1.3/Modules/selectmodule.o
./Python-3.1.3/Modules/rotatingtree.o
./Python-3.1.3/Modules/sha1module.o
./Python-3.1.3/Modules/unicodedata.o
./Python-3.1.3/Modules/parsermodule.o
./Python-3.1.3/Modules/xxsubtype.o
./Python-3.1.3/Modules/_heapqmodule.o
./Python-3.1.3/Modules/audioop.o
./Python-3.1.3/Modules/_multiprocessing/win32_functions.o
./Python-3.1.3/Modules/_multiprocessing/semaphore.o
./Python-3.1.3/Modules/_multiprocessing/pipe_connection.o
./Python-3.1.3/Modules/_multiprocessing/multiprocessing.o
./Python-3.1.3/Modules/_multiprocessing/socket_connection.o
./Python-3.1.3/Modules/_bisectmodule.o
./Python-3.1.3/Modules/gcmodule.o
./Python-3.1.3/Modules/_sre.o
./Python-3.1.3/Modules/_json.o
./Python-3.1.3/Modules/mathmodule.o
./Python-3.1.3/Modules/signalmodule.o
./Python-3.1.3/Modules/pyexpat.o
./Python-3.1.3/Modules/binascii.o
./Python-3.1.3/Modules/_pickle.o
./Python-3.1.3/Objects/unicodeobject.o
./Python-3.1.3/Objects/enumobject.o
./Python-3.1.3/Objects/codeobject.o
./Python-3.1.3/Objects/methodobject.o
./Python-3.1.3/Objects/moduleobject.o
./Python-3.1.3/Objects/cobject.o
./Python-3.1.3/Objects/exceptions.o
./Python-3.1.3/Objects/floatobject.o
./Python-3.1.3/Objects/unicodectype.o
./Python-3.1.3/Objects/bytesobject.o
./Python-3.1.3/Objects/weakrefobject.o
./Python-3.1.3/Objects/fileobject.o
./Python-3.1.3/Objects/structseq.o
./Python-3.1.3/Objects/memoryobject.o
./Python-3.1.3/Objects/dictobject.o
./Python-3.1.3/Objects/classobject.o
./Python-3.1.3/Objects/setobject.o
./Python-3.1.3/Objects/object.o
./Python-3.1.3/Objects/obmalloc.o
./Python-3.1.3/Objects/cellobject.o
./Python-3.1.3/Objects/descrobject.o
./Python-3.1.3/Objects/tupleobject.o
./Python-3.1.3/Objects/typeobject.o
./Python-3.1.3/Objects/genobject.o
./Python-3.1.3/Objects/iterobject.o
./Python-3.1.3/Objects/listobject.o
./Python-3.1.3/Objects/bytearrayobject.o
./Python-3.1.3/Objects/frameobject.o
./Python-3.1.3/Objects/boolobject.o
./Python-3.1.3/Objects/longobject.o
./Python-3.1.3/Objects/funcobject.o
./Python-3.1.3/Objects/complexobject.o
./Python-3.1.3/Objects/rangeobject.o
./Python-3.1.3/Objects/capsule.o
./Python-3.1.3/Objects/bytes_methods.o
./Python-3.1.3/Objects/abstract.o
./Python-3.1.3/Objects/sliceobject.o
msg123475 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2010-12-06 16:11
Thanks for the explanations! These instructions should be turned into a patch.
Some questions already:
- Why is the generated pyconfig.h not good enough? Could we modify the ./configure script instead?
- the "empty.c" should remain empty... Why not use PC/WinMain.c instead?
- why is a WinMain required when python.c is supposed to define a main()?
Is the final binary a console application or a Windows application?
msg123489 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-12-06 18:47
> As for the reproducibility issue: The configure/Makefile system
> coming with Python simply doesn't support creating a Windows build. I
> hope it's clear that the patch is NOT about creating a Windows
> installer. If this is a requirement for getting my patch in, please
> let me know so I can stop wasting my time!

That's why I was asking what the patch achieves - it was not clear
at all what the objective is. Not supporting the build of an installer
is fine (although that probably wouldn't be difficult). However, if
the patch doesn't manage to make "configure;make" work, it's IMO
useless. Having "make install" work in some form would be desirable.
msg123523 - (view) Author: Johann Hanne (jonny) Date: 2010-12-07 06:54
- Why is the generated pyconfig.h not good enough? Could we modify the ./configure script instead?
Probably setup.py needs to be extended; I did not have a deep look into the build system though

- the "empty.c" should remain empty... Why not use PC/WinMain.c instead?
It seems to be that MinGW does not support the wWinMain unicode entry point; the empty.c hack is just to show that it's actually linking

- why is a WinMain required when python.c is supposed to define a 
main()?
Good question; probably just a question of linker flags; I will have a look if my time permits

- Is the final binary a console application or a Windows application?
A Console application; creating a GUI application is easily done with the "-mwindows" gcc flag, but then you will have no Python console when not using idle or similar
msg123526 - (view) Author: Johann Hanne (jonny) Date: 2010-12-07 07:13
> However, if the patch doesn't manage to make "configure;make" work, it's IMO useless.
No, it's not, for two reasons:
- Embedding Python by just compiling/linking all the .c files in seems to be a major feature to me; so fixing compilation is useful for its own
- The win32 build system has never used "configure;make", but a Visual Studio project file; so why require it for a MinGW build?!

> Having "make install" work in some form would be desirable.
It would be a "nice to have". But there is one thing: The patch in its current form is trivial and next to impossible to break anything, yet I'm sure it's useful for a number of people. It's a result of work done within the company I'm working for. Submitting the patch does not have an immediate benefit for my company, it only will save me a (short!) amount of time because I will not to have to re-apply the patch for every new Python release. This time saving is the only justification for spending some working time to try to get it into the official tree.

As I have the feeling that all the discussion (which for the major part I used my spare time already...) is taking too much time, I will stop doing it as part of my job. As I'm privately interested in open source projects, I will continue to have a look at fixing "configure;make" for MinGW; but given my very limited spare time, this might take some weeks...
msg123530 - (view) Author: Johann Hanne (jonny) Date: 2010-12-07 07:27
Two corrections for the "configure;make" workaround:
- WRONG: Remove the created pyconfig.h and replace PC/pyconfig.h with the manually modified version I'm attaching
- CORRECT: Remove PC/pyconfig.h and replace the created pyconfig.h with the manually modified version I'm attaching
- Modules/config.c needs to modified as well:
-- Replace PyInit_posix by PyInit_nt (two occurences), "posix" by "nt" (in _PyImport_Inittab)
-- Remove '{"pwd", PyInit_pwd},' in _PyImport_Inittab
msg123578 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-12-07 19:28
> - Embedding Python by just compiling/linking all the .c files in
> seems to be a major feature to me; so fixing compilation is useful
> for its own

If that's the objective of the patch, I'm -1 on it.

> - The win32 build system has never used "configure;make", but a
> Visual Studio project file; so why require it for a MinGW build?!

Well, if MingW could use the VS project files, that would be fine
with me as well... We need *some* build procedure. Just being
able to compile the source files is not maintainable.

> It would be a "nice to have". But there is one thing: The patch in
> its current form is trivial and next to impossible to break anything,
> yet I'm sure it's useful for a number of people. It's a result of
> work done within the company I'm working for. Submitting the patch
> does not have an immediate benefit for my company, it only will save
> me a (short!) amount of time because I will not to have to re-apply
> the patch for every new Python release. This time saving is the only
> justification for spending some working time to try to get it into
> the official tree.

Understood. Perhaps somebody else is interested in picking up the
patch.

BTW, you do have your employer's permission to contribute this work,
right?
msg185821 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2013-04-02 07:09
#17605 titled "mingw-meta: build interpeter core" was opened on 2013-03-31 so I believe this can be closed as superseded.
msg193253 - (view) Author: Roumen Petrov (rpetrov) * Date: 2013-07-17 20:57
This patch cannot be closed as contain some fixes not reported/proposed yet .  
For instance I'm not aware of name clash in Modules/_pickle.c .
I think that other are in scope of issue3871 or earlier .
History
Date User Action Args
2022-04-11 14:57:09adminsetgithub: 54824
2021-10-21 10:04:27iritkatrielsetresolution: duplicate -> wont fix
2021-10-20 12:59:07iritkatrielsetstatus: open -> closed
superseder: MinGW is unsupported - close all open issues and list them here.
resolution: duplicate
stage: resolved
2020-11-11 18:52:01iritkatrielsetversions: + Python 3.8, Python 3.9, Python 3.10, - Python 3.1, Python 2.7, Python 3.2
2014-02-03 17:05:12BreamoreBoysetnosy: - BreamoreBoy
2013-07-17 20:57:12rpetrovsetmessages: + msg193253
2013-04-02 07:09:00BreamoreBoysetnosy: + BreamoreBoy
messages: + msg185821
2011-02-15 23:15:33schmirsetnosy: + schmir
2010-12-07 19:28:21loewissetmessages: + msg123578
2010-12-07 07:27:43jonnysetmessages: + msg123530
2010-12-07 07:13:06jonnysetmessages: + msg123526
2010-12-07 06:54:22jonnysetmessages: + msg123523
2010-12-06 18:47:00loewissetmessages: + msg123489
2010-12-06 16:11:20amaury.forgeotdarcsetmessages: + msg123475
2010-12-06 12:32:44jonnysetmessages: + msg123464
2010-12-06 12:22:58jonnysetfiles: + pyconfig.h

messages: + msg123463
2010-12-04 23:34:38amaury.forgeotdarcsetmessages: + msg123409
2010-12-04 22:59:53loewissetmessages: + msg123407
2010-12-04 21:23:44amaury.forgeotdarcsetmessages: + msg123405
2010-12-04 21:04:03amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg123404
2010-12-04 20:06:52loewissetmessages: + msg123397
2010-12-04 20:03:59jonnysetmessages: + msg123396
2010-12-04 19:47:33loewissetmessages: + msg123391
2010-12-04 19:33:40eric.araujosetnosy: + eric.araujo

versions: + Python 2.7, Python 3.2
2010-12-04 19:26:30jonnysetmessages: + msg123386
2010-12-04 08:44:53loewissetmessages: + msg123320
2010-12-04 08:32:32jonnysetmessages: + msg123318
2010-12-03 22:54:47rpetrovsetnosy: + rpetrov
2010-12-03 22:40:49loewissetnosy: + loewis
messages: + msg123302
2010-12-03 12:45:42jonnycreate