I'm running tests on Windows with this patch:
diff --git a/distutils/ccompiler.py b/distutils/ccompiler.py
index f4a8a897..6b0be67a 100644
--- a/distutils/ccompiler.py
+++ b/distutils/ccompiler.py
@@ -1058,7 +1058,7 @@ _default_compilers = (
('cygwin.*', 'unix'),
# OS name mappings
('posix', 'unix'),
- ('nt', 'msvc'),
+ ('nt', 'mingw32'),
)
There are 2 failed tests. Except for a failed test in distutils/tests/test_msvccompiler.py because of DistutilsPlatformError: Unable to find vcvarsall.bat, the other one is in distutils/tests/test_ccompiler.py::test_has_function_prototype:
---------------------------- Captured stderr call -----------------------------
...
ld.exe: cannot find -lvcruntime140: No such file or directory
collect2.exe: error: ld returned 1 exit status
------------------------------ Captured log call ------------------------------
INFO root:spawn.py:38 gcc -mdll -O -Wall -c AppData\Local\Temp\abortuj8w3z0y.c -o appdata\local\temp\abortuj8w3z0y.o
INFO root:spawn.py:38 gcc -s appdata\local\temp\abortuj8w3z0y.o -lvcruntime140 -o a.out.exe
While building extensions, ld doesn't complain -lvcruntime140 because vcruntime140.dll can be found in -LC:/Program Files/PythonXY/. However, get_msvcr() seems to be considered as a system libaray, which is linked unconditionally without library_dirs.
AFAIK mingw-w64 never links to msvcrXY or vcruntime140, it only links to either msvcrt or ucrt (which is talked about in #196), and -lvcruntime140 also seems to be a no-op. I don't know why get_msvcr is added at that time, I guess it was for the old mingw and is no longer needed for mingw-w64 nowadays. The old mingw is dying, there's no reason to use it instead of mingw-w64 and it's OK to drop support for it.
The question is, should we simply remove get_msvcr and rename Mingw32CCompiler to Mingw64CCompiler? The compiler type mingw32 can be deprecated and kept for backwards compatibility. I'm not sure how will it affect cygwin, I haven't investigate it. After it getting done, we can add mingw-w64 compiler to CI tests (Clarification: It's different from #184, that PR is for mingw-w64 compiled CPython, while what suggest here is for the "official" MSVC compiled CPython.)
Any ideas?
I'm running tests on Windows with this patch:
There are 2 failed tests. Except for a failed test in distutils/tests/test_msvccompiler.py because of
DistutilsPlatformError: Unable to find vcvarsall.bat, the other one is in distutils/tests/test_ccompiler.py::test_has_function_prototype:While building extensions, ld doesn't complain
-lvcruntime140because vcruntime140.dll can be found in-LC:/Program Files/PythonXY/. However,get_msvcr()seems to be considered as a system libaray, which is linked unconditionally without library_dirs.AFAIK mingw-w64 never links to msvcrXY or vcruntime140, it only links to either msvcrt or ucrt (which is talked about in #196), and
-lvcruntime140also seems to be a no-op. I don't know why get_msvcr is added at that time, I guess it was for the old mingw and is no longer needed for mingw-w64 nowadays. The old mingw is dying, there's no reason to use it instead of mingw-w64 and it's OK to drop support for it.The question is, should we simply remove get_msvcr and rename
Mingw32CCompilertoMingw64CCompiler? The compiler typemingw32can be deprecated and kept for backwards compatibility. I'm not sure how will it affect cygwin, I haven't investigate it. After it getting done, we can add mingw-w64 compiler to CI tests (Clarification: It's different from #184, that PR is for mingw-w64 compiled CPython, while what suggest here is for the "official" MSVC compiled CPython.)Any ideas?