pyMinGW: issues

Issues with pyMinGW

You are here: pyMinGW home | issues

SUMMARY

Except for the ctypes callback tests, all Python 2.5a2 regresion tests pass now under WinXP SP2, and all tests pass for Python 2.4.3 under WinXP SP2.

On Win98, on the other hand, test_threaded_import for both Python 2.4.3, and Python 2.5a2 is still not passing if the whole test suit is run (it passes when called on its own); that, test_bsddb3, and the Python 2.5a2 ctypes callbacks tests aside, all other tests pass as expected.

Tix can now be built in MinGW and is now supported. MinGW still lacks support for IPv.6, however.

Please be informed that mixing MSVCRT (which MinGW uses) and MSVCR71 (which the official Python uses) is still calling for trouble. See the section MSVCRT and MSVCR71 below for more details.

1. WinXP
Except for the callbacks tests of the ctypes extension, all tests pass as expected in Python 2.5a2 on WinXP SP2. But as is the case with Win98, MinGW still does not support IPv.6.

2. Win98
In addition to the IPv.6 and runtime library matters noted above, there are currently two known issues with the pyMinGW patched and MinGW compiled Python running under Win98.

2.1. bsddb3 on Win98
Running test_bsdd3 on both Python 2.5a2, and Python 2.4.3 yeilds 4 errors on Win98. It is my understanding that Win98 is not that well supported by sleepycat's Berkeley DB database. Here is a quote from the Subversion project's FAQs:

What operating systems does Subversion run on?

All modern flavors of Unix, Win32, BeOS, OS/2, MacOS X.

Subversion is written in ANSI C and uses APR, the Apache Portable Runtime library, as a portability layer. The Subversion client will run anywhere APR runs, which is most places. The Subversion server (i.e., the repository side) is the same, except that it will not host a BDB repository on Win9x platforms (Win95/Win98/WinME), because Berkeley DB has shared-memory segment problems on Win9x. FSFS repositories (introduced in version 1.1) do not have this restriction; however, due to a limitation in Win9x's file-locking support, they also don't work in Win9x. That limitation will hopefully be worked around in 1.1.2.

With that said, let's report on these errors. We get 4 errors in Python 2.4.3 final on Win98. Some of the expected errors, we are told, are common to other platforms as per the \PCBuild\readme.txt file. Here is a quote from that file:

    XXX The test_bsddb3 tests don't always pass, on Windows (according to
    XXX me) or on Linux (according to Barry).  (I had much better luck
    XXX on Win2K than on Win98SE.)  The common failure mode across platforms
    XXX is
    XXX     DBAgainError: (11, 'Resource temporarily unavailable -- unable
    XXX                         to join the environment')
    XXX
    XXX and it appears timing-dependent.

2.1.1. bsddb3 in Python 2.5a2, and Python 2.4.3 on Win98
Here is the summary of the output of test_bsddb3 in Python 2.4.3 on Win98:

======================================================================
ERROR: test01_basics (bsddb.test.test_dbshelve.EnvBTreeShelveTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "G:\PROJS\PY24\PYTHON\R24\lib\bsddb\test\test_dbshelve.py", line 75, in test01_basics
    self.do_open()
  File "G:\PROJS\PY24\PYTHON\R24\lib\bsddb\test\test_dbshelve.py", line 238, in do_open
    self.env.open(homeDir, self.envflags | db.DB_INIT_MPOOL | db.DB_CREATE)
DBRunRecoveryError: (-30974, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Input/output error')

======================================================================
ERROR: test01_basics (bsddb.test.test_dbshelve.EnvHashShelveTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "G:\PROJS\PY24\PYTHON\R24\lib\bsddb\test\test_dbshelve.py", line 75, in test01_basics
    self.do_open()
  File "G:\PROJS\PY24\PYTHON\R24\lib\bsddb\test\test_dbshelve.py", line 238, in do_open
    self.env.open(homeDir, self.envflags | db.DB_INIT_MPOOL | db.DB_CREATE)
DBRunRecoveryError: (-30974, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Input/output error')

======================================================================
ERROR: test01_basics (bsddb.test.test_dbshelve.EnvThreadBTreeShelveTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "G:\PROJS\PY24\PYTHON\R24\lib\bsddb\test\test_dbshelve.py", line 75, in test01_basics
    self.do_open()
  File "G:\PROJS\PY24\PYTHON\R24\lib\bsddb\test\test_dbshelve.py", line 238, in do_open
    self.env.open(homeDir, self.envflags | db.DB_INIT_MPOOL | db.DB_CREATE)
DBRunRecoveryError: (-30974, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Input/output error')

======================================================================
ERROR: test01_basics (bsddb.test.test_dbshelve.EnvThreadHashShelveTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "G:\PROJS\PY24\PYTHON\R24\lib\bsddb\test\test_dbshelve.py", line 75, in test01_basics
    self.do_open()
  File "G:\PROJS\PY24\PYTHON\R24\lib\bsddb\test\test_dbshelve.py", line 238, in do_open
    self.env.open(homeDir, self.envflags | db.DB_INIT_MPOOL | db.DB_CREATE)
DBRunRecoveryError: (-30974, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Input/output error')

2.2. test_threaded_import on win98
When run from either Python 2.5a2, or Pytohn 2.4.3, this test fails on Win98, when run inside the test suit with test_tcl run before it (i.e. tcl must be installed), with the message that the Operating System (OS) cannot create more threads, or something to that effect. This test passes when run on its own or when run on WinXP, however. Based on that information, I was inclined to think that this is an OS resource management issue. However, this test passes in the standard Python distribution. So either we are missing something, or MinGW is.

3. Sockets
MinGW still lacks support for IPv.6. pyMinGW will use some of the facilities provided in the emulation layer provided in Python's source. But the point is that we do not have IPv.6 support yet.

4. MSVCRT and MSVCR71
The pyMinGW build of Python 2.4 currently uses the default MinGW choice of MSVCRT as its common runtime library as opposed to the official Python distribution's, namely the MSVCR71. The reason for this being that as of this writing MinGW still cannot link with MSVCR71 as easily as it can with the default MSVCRT, especailly when it comes to complex projects that require the linking of several object files as is the case with Python's DLLs.

It is still the the case that, and just like in the matter of the MSVC V6 build Python, it is not safe to extend Python which relies on MSVCR71 with an extension that relies on MSVCRT. Likewise, it is unsafe to extended Python which relies on MSVCRT with an extension that relies on MSVCR71.

And so until MinGW begins to support using MSVCR71 without problems, I am afraid that you-- and like those who compiled their Python in MSVC V6-- will have to download the sources and compile the extensions you need yourself in MinGW. This way your pyMinGW Python build and your MinGW compiled extension(s) will both be using the same runtime library. That should shield you from this run-time mess.

4.1. Extending the official Python 2.4+ distributions
Let's digress here to mention extending the official Python 2.4+ with MinGW. If you wish to extend the official (I repeat: the official) Python 2.4+ distributions with simple MinGW compiled extension(s) you could try changing the specs file found in "%MinGWpath%\lib\gcc\%MinGWversion%\specs" and changing the entry that reads -lmsvcrt to -lmsvcr71.

That and forcing your distutils cygwinccompiler.py (see patch below) to link with -lmsvcr71 should in theory help you create extensions that rely only on msvcr71 and hence re safe to use in the official Python 2.4+ distribution(s). Here is how you should change your cygwinccompile.py:

--- cygwinccompiler.py	Sat Dec 24 09:47:00 2004
+++ cygwinccompiler2.py	Sat Dec 24 09:49:20 2004
@@ -317,7 +317,8 @@
         # (-mthreads: Support thread-safe exception handling on `Mingw32')
 
         # KAB: changed [] to ['python' + version], which we need.
-        self.dll_libraries=['python' + ''.join(sys.winver.split('.'))]
+        # Add 'msvcr71' only to extend the official Python 2.4 
+        self.dll_libraries=['msvcr71', 'python' + ''.join(sys.winver.split('.'))]
 
         # Include the appropriate MSVC runtime library if Python was built
         # with MSVC 7.0 or 7.1.

Please be reminded that these same extensions that rely on MSVCR71 are not for the pyMinGW-24+ compiled Python or the MSVC V6 compiled Python 2.4+. To extend your pyMinGW-24+ Python build(s), you don't need to do any special steps. And your extensions should be safe to use with Python builds that use the MSVCRT library.

4.1.1 Update
Starting from May of 2006, pyMinGW includes tools both standalone and also embedded in distutils that allow extension authors to use MinGW to extend standard Python 2.4+ with extensions that rely only on MSVCR71. Please type switchDLL -h in your pyMinGW root directory (i.e. MinGW) for more information, or use the --fix-runtime as an option to your setup.py file as follows: python setup.py build_ext --fix-runtime. Using these new pyMinGW tools alone (i.e. without editing spec or Python source files as mentioned above) has so far proved enough to make extensions that rely soley on MSVCR71 and so making them safe to use in the standard Python distribution.

While testing the tools, I transformed all Python binary files to use MSVCR71 instead of MSVCRT and then ran the entire Python test suit. All the time the transformed Python behaved like the "native one." Not one crash, not one unexpected failure.

Old stuff
The old issues file(s), kept for historical reasons only, can be found here.

Back to top