Re: [igraph] Windows build requirements for 0.6

[Gábor Csárdi]

There is not much difference I believe. The reason for 2003 was that
Python was compiled with that as well.

Gabor

On Wed, Mar 4, 2009 at 6:01 PM, Chris Wj <address@hidden> wrote:
> So best bet = Visual Studio 2003 (7.1)... Any plans on using a newer
> version? or stick with that one?
>
> -Chris
>
> On Wed, Mar 4, 2009 at 9:31 AM, Tamas Nepusz <address@hidden> wrote:
>>>>
>>>> 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.
>>
>>
>> _______________________________________________
>> igraph-help mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
> _______________________________________________
> igraph-help mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/igraph-help
>
>



-- 
Gabor Csardi <address@hidden>     UNIL DGM