Embedded python 2.6 interpreter can't "import sqlite3" on Windows XP

[jdetaeye]

I am porting an application which embeds a Python interpreter to
Python 2.6.
On version 2.5 all is working fine, but importing the sqlite3 module
doesn't work any more on 2.6.

The statement "import sqlite3" does work fine when executed from in
the python command prompt, ie not from the embedded interpreter.
The same import gives the following error when executed from the
embedded interpreter.
Python stacktrace:
Traceback (most recent call last):
File "<string>", line 2, in <module>
File "C:\Python26\lib\sqlite3\__init__.py", line 24, in
<module>
from dbapi2 import *
File "C:\Python26\lib\sqlite3\dbapi2.py", line 27, in
<module>
from _sqlite3 import *
ImportError: DLL load failed: A dynamic link library (DLL)
initialization routine failed.
Windows popup window:
Runtime Error!
R6034
An application has made an attempt to load the C runtime
library incorrectly.
Please contact the application's support team for more
information.

Unfortunately the "application support team" (that is me has no
idea on how to move forward on this:
a) I guess this is releated to the problem with manifest files,
already reported in http://bugs.python.org/issue4120 ?
b) What could be a solution or workaround for the problem?

All the above is on Windows XP.
Other modules with have an extension DLL (such as ssl) give exactly
the same problem.

All help appreciated,

Johan

 

[Peter]

I am porting an application which embeds a Python interpreter to
Python 2.6.
On version 2.5 all is working fine, but importing the sqlite3 module
doesn't work any more on 2.6.

The statement "import sqlite3" does work fine when executed from in
the python command prompt, ie not from the embedded interpreter.
The same import gives the following error when executed from the
embedded interpreter.
Python stacktrace:
Traceback (most recent call last):
File "<string>", line 2, in <module>
File "C:\Python26\lib\sqlite3\__init__.py", line 24, in
<module>
from dbapi2 import *
File "C:\Python26\lib\sqlite3\dbapi2.py", line 27, in
<module>
from _sqlite3 import *
ImportError: DLL load failed: A dynamic link library (DLL)
initialization routine failed.
Windows popup window:
Runtime Error!
R6034
An application has made an attempt to load the C runtime
library incorrectly.
Please contact the application's support team for more
information.

Unfortunately the "application support team" (that is me has no
idea on how to move forward on this:
a) I guess this is releated to the problem with manifest files,
already reported in http://bugs.python.org/issue4120 ?
b) What could be a solution or workaround for the problem?

All the above is on Windows XP.
Other modules with have an extension DLL (such as ssl) give exactly
the same problem.

All help appreciated,

Johan

Python 2.6+ was built with Visual Studio 2008; therefore, the Microsoft
Visual C++ 2008 Redistributable Package (run time libraries) must be
installed on the computer that you are trying to run your python
application. If the computer already has Python 2.6+ installed "for all
users", then the run time libraries should already be installed in
c:\windows\winsxs. On computers that do not have Python 2.6+ installed
(or it was installed using "Install Just for Me"), you probably will
need to install the Visual C++ 2008 Redistributable Package. It is
possible that some other application already installed the correct run
time libraries in the c:\windows\winsxs directory.

Visual C++ 2008 Redistributable Package:
http://www.microsoft.com/downloads/...34-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en

After installing the Visual C++ 2008 Redistributable, you can find it
under the c:\windows\winsxs directory.

Side-by-Side (sxs) Assemblies are Microsoft's answer to "DLL hell" and
Visual C++ 2005 had them, too. I believe the reason the Python
community didn't see these problems earlier was that most computers
already had the proper run time libraries installed. See "Application
Compatibility—Side-by-side Assemblies" in
http://msdn.microsoft.com/en-us/magazine/cc302206.aspx and
http://msdn.microsoft.com/en-us/magazine/ms997620.aspx for more
information on Side-by-Side Assemblies.

Note that if future versions of Python are built with Visual Studio 2008
with service pack (SP) #x and the build specifies that the SP #x updated
run time libraries should be used, then you'll need to install the
updated run time libraries. See
http://msdn.microsoft.com/en-us/library/cc664727.aspx and
http://msdn.microsoft.com/en-us/library/ms235299(VS.80).aspx for more
information on binding applications to specific run time libraries.

The following articles may also be of interest:

http://msdn.microsoft.com/en-us/library/ms235531.aspx
http://msdn.microsoft.com/en-us/library/ms235342.aspx
http://msdn.microsoft.com/en-us/library/aa374224.aspx

Of course everything I've just said may change with the next release of
Python, because the Python maintainers are apparently looking at
alternative ways around this issue. Although I'm not a Microsoft fan,
I'm not yet convinced that trying to work around Microsoft's winsxs
requirements is a smart thing to do.

It might simplify things for python users and developers if the Python
2.6+ installers always installed the VS C++ run time libraries into the
winsxs directory. Perhaps python tools that create embedded python
applications could better document this issue, so that people using
embedded applications will know that they have to install the proper run
time libraries. It's also possible that Microsoft will someday install
these new Visual Studio 2008 run time libraries via their update service
or a future service pack.

Peter