Robin Dunn <robin <at> alldunn.com> writes:
You may need to ask about this in some other place (distutils-sig for
example) because it is starting to get beyond what I know. Python
requires that the extension modules be compiled with a compiler that
has a runtime that is compatible with what was used to compile python
itself. For MS compilers this usually means that it must be the same
version. Looking at the code in msvccompiler.py it looks like it is
trying to find the info it needs for the same version by using the
compiler version recorded in the sys.version string, and is raising that
exception if it can't find it. The VS 2003 is hard coded in the error
message and it appears it will say that no matter which version of the
compiler it is actually looking for and can't find.
thanks again for response. My experience with Msoft is that they tend to keep
things backwards compatible as much as possible. I assumed as much and treated
the command line compiler, cl.exe, in the same way I treated it many years ago,
by trying to compile one source file. In this case, it was crc32.c from the
zlib package. It had already compiled adler.c and one other source file but it
choked on crc32.c.
After a few frustrating hours of not wanting to interpret the long cl.exe
command line, I took the plunge, to the point where I could understand each
command it used, and each path. That's where the problem lay. The makefile that
addressed the compilation of crc32.c had a slightly different command line than
the two that had already compiled. I duplicated the command line of the two
previous successful compilations and off it went.
It got a little tricky later on, but through wheedling the makefile, I got all
the wxWindows libraries compiled. It's clear that Visual Studio 9.0 works for
compiling the packages then. I duplicated the compilation using Visual Studio
9's IDE, so it works too.
To anyone else struggling with this, I strongly recommend learning the PATH
systems used in Windows and Unix. Windows uses a system path and a user path,
with the system path having preference. In other words, anything entered in the
system path is searched first. I found a script that sets the path in Cygwin at
startup and that helped immensely. I put it in bashrc, bash-profile, profile
and anywhere else it would fit. I have found that to be one of the crucial
things with getting Cygwin to interact with Windows....get the paths worked
out.
Now I'm trying to compile wxPython and have encountered an entirely different
problem. The makefiles for wxPython are written differently and written for
Unix. They start to work using Cygwin if the path is correct, but I've run into
a problem where bash is looking for the linker in /usr/bin instead of the
Visual Studio directory. I think I can fix that, but I'm stumped by a
peculiarity in Cygwin. There are no files seen in the /usr/bin directory from
Windows although there are tons of them when viewed from bash using ls -l. The
rub is that bash can't find them itself when running out of a /cygdrive mounted
Windows directory.
I realize this is probably off topic, so I'll leave it at that. Thanks for your
help.