Re: [igraph] Windows build requirements for 0.6

[Tamas Nepusz]

> > I have successfully compiled igraph 0.6 in the cygwin environment  
> > (using
> > cygwin's python), but I would like to be able to use the native  
> > Python and
> > not have the cygwin dependencies. I have tried MinGW and MSYS with  
> > lots of
> > headache.
> We failed to build the previous version with MinGW and/or MSYS. If I
> recall it well, the problem was that Python was built with an old
> version of Visual Studio, but maybe not.
The problem is more complex than that. Quoting a mail from the Python  
mailing list in Jan 2007:

"The binary installer for Python built by te python.org team is  
compiled with Microsoft Visual Studio 2003. It is linked with the C  
runtime msvcr71.dll. The copyright to msvcrt71.dll is owned by  
Microsoft, and it is not an integral part of the Windows operating  
system."
http://mail.python.org/pipermail/python-list/2007-January/423306.html

Now, building with Cygwin is definitely not an option because of the  
dependency on cygwin1.dll. Building with MinGW is not an option either  
for the time being, as MinGW links to MSVCRT.DLL, which is (surprise!)  
slightly incompatible with MSVCR71.DLL. This materialises in various  
linker errors while building the Python extension (the linker tries to  
look up a function in MSVCR71.DLL that used to exist in MSVCRT.DLL but  
disappeared in the meanwhile; it is even more annoying that that  
specific function is not used by us at all, but maybe an extra  
#include brings that in). Even if we somehow manage to link the  
extension to the C core, it might happen that a) Python is not able to  
import it (Python has MSVCR71.DLL; if we link to MSVCRT.DLL in MinGW,  
that's a no-go); b) funny things happen when a FILE* pointer is passed  
from the Python layer (using FILE* from MSVCR71.DLL) to the C layer  
(using FILE* from MSVCRT.DLL which is incompatible on the binary  
level). If you google for "msvcrt msvcr71 python extensions", you'll  
get a whole lot of search results trying to deal with this issue, but  
none of them worked for us. I even tried to hack MinGW to link to  
MSVCR71.DLL (which involved recompiling some part of the MinGW runtime).

--
T.