Trouble building pywin32 with Visual Studio 2005

D

danfike

Hi everybody...

I'm hoping one of you reading this can help me out here. I'm having
trouble getting pywin32 to build with Visual Studio 2005. But first,
some background.

I'm embedding Python in an MFC application. I've manually built
Python .lib and .dll files using Visual Studio 2005 from the solution/
project files in the PCBuild8 folder. I've got a totally happy,
working Python interpreter in my MFC application.

When I use pre-built pywin32 packages, some strange crashes occur.
Specifically, if I import win32com.server.register and call the
RegisterClasses function, I get a complaint regarding an attempt to
free unallocated memory.

Now, my theory on this issue is that DLLs like win32api.pyd, which I
acquired pre-built, were built with Visual Studio 2003, and they
depend on msvcr71.dll. My Python/MFC application, on the other hand,
was built with Visual Studio 2005, and is linking with msvcr80.dll. If
memory gets allocated through one DLL, and an attempt is made at
freeing it in the other DLL, bad things can happen, since the freeing
DLL doesn't have any header information on the allocated memory.

In order to test this theory (and potentially fix it), I want to re-
build the pywin32 stuff using Visual Studio 2005. Now I've never built
pywin32, so please excuse any "noobness" from here on out. I
downloaded the pywin32-210.zip source from sourceforge. I tried
running "setup.py build" per the Readme, and I received the following
message.

Warning - can't find an installed platform SDK
error: Python was built with Visual Studio 2003;
extensions must be built with a compiler that can generate compatible
binaries. Visual Studio 2003 was not found on this system. if you have
Cygwin installed, you can try compiling with MingW32, by passing "-c
mingw32" to setup.py.

(Note that I don't have the Platform SDK - This is a Vista machine, so
I've got what they now are calling the Windows SDK. If it ends up
being a problem, I'll tackle it when it shows up)

The logical conclusion to jump to from this error message is that
pywin32 is trying to build with VS2005, but it thinks that Python was
built with VS2003. Well, in a manner of speaking, that is true. I did
have a regular Python installation in C:\Python25, straight from one
of the MSI installers. That regular Python installation was
undoubtedly compiled with VS2003. I guess what I need to do is find a
way to replace the default installation, or certain files within it,
with stuff I compiled myself using VS2005. I tried replacing all of
the python25[_d].dll and python[w][_d].exe files with those that I
built, and that isn't helping. I considered creating a Python
installer with the msi.py that is included in the Python Source, but
that requires pywin32 (according to the README), and that's what I'm
trying to build.

I tried going through the setup.py code to find out where it is
acquiring this "Python was built with Visual Studio 2003" information,
but I keep getting lost in the code, so I can't figure out which, if
any, file(s) to change/replace.
 
K

kyosohma

Hi everybody...

I'm hoping one of you reading this can help me out here. I'm having
trouble getting pywin32 to build with Visual Studio 2005. But first,
some background.

I'm embedding Python in an MFC application. I've manually built
Python .lib and .dll files using Visual Studio 2005 from the solution/
project files in the PCBuild8 folder. I've got a totally happy,
working Python interpreter in my MFC application.

When I use pre-built pywin32 packages, some strange crashes occur.
Specifically, if I import win32com.server.register and call the
RegisterClasses function, I get a complaint regarding an attempt to
free unallocated memory.

Now, my theory on this issue is that DLLs like win32api.pyd, which I
acquired pre-built, were built with Visual Studio 2003, and they
depend on msvcr71.dll. My Python/MFC application, on the other hand,
was built with Visual Studio 2005, and is linking with msvcr80.dll. If
memory gets allocated through one DLL, and an attempt is made at
freeing it in the other DLL, bad things can happen, since the freeing
DLL doesn't have any header information on the allocated memory.

In order to test this theory (and potentially fix it), I want to re-
build the pywin32 stuff using Visual Studio 2005. Now I've never built
pywin32, so please excuse any "noobness" from here on out. I
downloaded the pywin32-210.zip source from sourceforge. I tried
running "setup.py build" per the Readme, and I received the following
message.

Warning - can't find an installed platform SDK
error: Python was built with Visual Studio 2003;
extensions must be built with a compiler that can generate compatible
binaries. Visual Studio 2003 was not found on this system. if you have
Cygwin installed, you can try compiling with MingW32, by passing "-c
mingw32" to setup.py.

(Note that I don't have the Platform SDK - This is a Vista machine, so
I've got what they now are calling the Windows SDK. If it ends up
being a problem, I'll tackle it when it shows up)

The logical conclusion to jump to from this error message is that
pywin32 is trying to build with VS2005, but it thinks that Python was
built with VS2003. Well, in a manner of speaking, that is true. I did
have a regular Python installation in C:\Python25, straight from one
of the MSI installers. That regular Python installation was
undoubtedly compiled with VS2003. I guess what I need to do is find a
way to replace the default installation, or certain files within it,
with stuff I compiled myself using VS2005. I tried replacing all of
the python25[_d].dll and python[w][_d].exe files with those that I
built, and that isn't helping. I considered creating a Python
installer with the msi.py that is included in the Python Source, but
that requires pywin32 (according to the README), and that's what I'm
trying to build.

I tried going through the setup.py code to find out where it is
acquiring this "Python was built with Visual Studio 2003" information,
but I keep getting lost in the code, so I can't figure out which, if
any, file(s) to change/replace.

Probably the easiest way to "fix" this is to use MinGW or VS2003 or
recompile your MFC using MingW against what amounts to VS2003. I've
heard from multiple sources that trying to compile "impure" Python
extensions against anything other than the original compiler can (and
does) lead to screwy issues.

Of course, there is the theory that you could compile your own Python
using VS2005 and then it should "just work"...but from what I've
heard, even the Python developers are skipping VS2005 and heading
straight to VS2008.

Not very helpful, I know. You may get better help from the people on
the PyWin32 user's group. See http://mail.python.org/mailman/listinfo/python-win32

Mike
 
?

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=

Now, my theory on this issue is that DLLs like win32api.pyd, which I
acquired pre-built, were built with Visual Studio 2003, and they
depend on msvcr71.dll. My Python/MFC application, on the other hand,
was built with Visual Studio 2005, and is linking with msvcr80.dll. If
memory gets allocated through one DLL, and an attempt is made at
freeing it in the other DLL, bad things can happen, since the freeing
DLL doesn't have any header information on the allocated memory.

That is the likely cause, yes.
In order to test this theory (and potentially fix it), I want to re-
build the pywin32 stuff using Visual Studio 2005.

That might not be sufficient. You have to rebuild Python itself as well.

The logical conclusion to jump to from this error message is that
pywin32 is trying to build with VS2005, but it thinks that Python was
built with VS2003. Well, in a manner of speaking, that is true. I did
have a regular Python installation in C:\Python25, straight from one
of the MSI installers. That regular Python installation was
undoubtedly compiled with VS2003. I guess what I need to do is find a
way to replace the default installation, or certain files within it,
with stuff I compiled myself using VS2005. I tried replacing all of
the python25[_d].dll and python[w][_d].exe files with those that I
built, and that isn't helping.

That is likely to happen. distutils doesn't actually *check* what CRT
or VC version Python was built with, instead, it *knows*, hardcoded.
I tried going through the setup.py code to find out where it is
acquiring this "Python was built with Visual Studio 2003" information,
but I keep getting lost in the code, so I can't figure out which, if
any, file(s) to change/replace.

If you know what you are doing, you can override the logic of distutils.
Set up an SDK environment (with LIBRARY, INCLUDE and everything), then
also set the MSSdk environment variable (which should get set if you
use the standard environment batch file from the SDK), and then also
set DISTUTILS_USE_SDK. Then distutils will trust that the environment
you set up works correctly, and will use it without further questioning.

HTH,
Martin
 
D

danfike

In order to test this theory (and potentially fix it), I want to re-
That might not be sufficient. You have to rebuild Python itself as well.

Either I misunderstand, or you do. If it wasn't clear, I have already
rebuilt Python using Visual Studio 2005.
The logical conclusion to jump to from this error message is that
pywin32 is trying to build with VS2005, but it thinks that Python was
built with VS2003. Well, in a manner of speaking, that is true. I did
have a regular Python installation in C:\Python25, straight from one
of the MSI installers. That regular Python installation was
undoubtedly compiled with VS2003. I guess what I need to do is find a
way to replace the default installation, or certain files within it,
with stuff I compiled myself using VS2005. I tried replacing all of
the python25[_d].dll and python[w][_d].exe files with those that I
built, and that isn't helping.

That is likely to happen. distutils doesn't actually *check* what CRT
or VC version Python was built with, instead, it *knows*, hardcoded.

Oof. Fair enough.
If you know what you are doing, you can override the logic of distutils.
Set up an SDK environment (with LIBRARY, INCLUDE and everything), then
also set the MSSdk environment variable (which should get set if you
use the standard environment batch file from the SDK), and then also
set DISTUTILS_USE_SDK. Then distutils will trust that the environment
you set up works correctly, and will use it without further questioning.

I'll see if I can get that working. During my internet searches, I
came across a mail/post/blog or two indicating DISTUTILS_USE_SDK does
not work in Visual Studio 2005. I'll see what I can do.
 
?

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=

Either I misunderstand, or you do. If it wasn't clear, I have already
rebuilt Python using Visual Studio 2005.

I see. I must have misunderstood then - if you already rebuilt Python
itself, all is fine.

Regards,
Martin
 
D

danfike

If you know what you are doing, you can override the logic of distutils.
I'll see if I can get that working. During my internet searches, I
came across a mail/post/blog or two indicating DISTUTILS_USE_SDK does
not work in Visual Studio 2005. I'll see what I can do.

I didn't have much luck with this. It looks like my solution is going
to be to just ignore this problem for now. In most cases, the binary
modules one downloads are written well enough that these DLLs aren't
going to step on eachother's toes. In fact, I haven't found a function
aside from win32com.server.register.RegisterClasses which has the same
problem. Now, if everybody moves to VS2008 for Python 3000, this
problem would work itself out. :)

Thanks for your help, Martin.

-Dan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top