MinGW and Python

[Neal Becker]

Re: MinGW and Python

Alex Martelli wrote:
[color=blue]
> sturlamolden <sturlamolden@y ahoo.no> wrote:
>[color=green]
>> Robert Kern wrote:
>>[color=darkred]
>> > Dunno. Depends on the machine. Depends on the program. Depends on how
>> > the interpreter and any extension modules and underlying libraries were
>> > built. Depends on which Linux and which Windows.
>> >
>> > I'm sorry, but your question is a non sequitur. I don't understand its
>> > relevance to this thread.[/color]
>>
>> The relevance: Python is built with GCC on Linux. Do you or do you not
>> see a performance hit on Linux?
>>
>> MinGW is GCC. Will you get a performance hit when building Python with
>> MinGW?[/color]
>
> I cannot predict this, though it would be great if somebody who does
> have both VS2003 and mingw could give it a try.
>
> What I did just post on another thread over the last couple of days is
> about MacOSX, which also uses gcc: 14% faster pybench using Python 2.4.3
> under Win2000 under Parallels Workstation beta, compared to 2.4.3
> Universal directly on MacOSX -- the standard build of 2.4.3 in either
> cause, i.e., the one built with MS compilers on Windows, vs the one
> built with Apple's gcc on MacOSX.
>
>
> Alex[/color]

Please when quoting such benchmarks include gcc version. gcc >= 4.1 is
supposed to have a lot of performance improvements. This is the current
release. Since mingw is usually current, I haven't checked, but they may
be using 4.1 now.

[Fredrik Lundh]

Re: MinGW and Python

Neal Becker wrote:
[color=blue][color=green]
>> What I did just post on another thread over the last couple of days is
>> about MacOSX, which also uses gcc: 14% faster pybench using Python 2.4.3
>> under Win2000 under Parallels Workstation beta, compared to 2.4.3
>> Universal directly on MacOSX -- the standard build of 2.4.3 in either
>> cause, i.e., the one built with MS compilers on Windows, vs the one
>> built with Apple's gcc on MacOSX.[/color][/color]
[color=blue]
> Please when quoting such benchmarks include gcc version. gcc >= 4.1 is
> supposed to have a lot of performance improvements. This is the current
> release. Since mingw is usually current, I haven't checked, but they may
> be using 4.1 now.[/color]

does
"the standard build of 2.4.3 in either case"

do you have trouble understanding ?

(what makes you think that 2.4.3 for windows is compiled with the best possible
compiler for the windows environment?)

</F>

[Fredrik Lundh]

Re: MinGW and Python

Neal Becker wrote:
[color=blue][color=green]
>> What I did just post on another thread over the last couple of days is
>> about MacOSX, which also uses gcc: 14% faster pybench using Python 2.4.3
>> under Win2000 under Parallels Workstation beta, compared to 2.4.3
>> Universal directly on MacOSX -- the standard build of 2.4.3 in either
>> cause, i.e., the one built with MS compilers on Windows, vs the one
>> built with Apple's gcc on MacOSX.[/color][/color]
[color=blue]
> Please when quoting such benchmarks include gcc version. gcc >= 4.1 is
> supposed to have a lot of performance improvements. This is the current
> release. Since mingw is usually current, I haven't checked, but they may
> be using 4.1 now.[/color]

what part of

"the standard build of 2.4.3 in either case"

do you have trouble understanding ?

(what makes you think that 2.4.3 for windows is compiled with the best possible
compiler for the windows environment?)

</F>

[Brian Elmegaard]

Re: MinGW and Python

Neal Becker <ndbecker2@gmai l.com> writes:
[color=blue]
> release. Since mingw is usually current, I haven't checked, but they may
> be using 4.1 now.[/color]

It is not, it is 3.4.2.

http://www.mingw.org/download.shtml#hdr2

--
Brian (remove the sport for mail)

http://www.et.web.mek.dtu.dk/Staff/be/be.html

http://www.rugbyklubben-speed.dk

[Martin v. Löwis]

Re: MinGW and Python

Edward Elliott wrote:[color=blue][color=green]
>> Well, there is no native C library on Microsoft Windows: the system
>> simply doesn't include an official C library (I know there is crtdll.dll
>> and msvcrt.dll, but these aren't "endorsed" system C libraries).[/color]
>
> don't know what you mean by "endorsed". does it lack features of the C89
> ANSI standard?[/color]

There isn't an import library for these DLLs anywhere, and Microsofts
documents it (msvcrt.dll) as not intended for application use:

http://msdn2.microsoft.com/en-us/lib...yh(VS.80).aspx

'The msvcrt.dll is now a "known DLL," meaning that it is a system
component owned and built by Windows. It is intended for future use only
by system-level components.'
[color=blue][color=green]
>> For Windows, that would require not to use any of the standard C
>> functionality, since the system doesn't provide that functionality out
>> of the box.[/color]
>
> That would be a problem then. So what happens when you compile python with
> msvc, and why can't mingw just replicate that?[/color]

I link with msvcr71.dll (currently). To distribute Python, I need to
include a copy of msvcr71.dll, which I can, because the MSVC license
allows me to redistribute that DLL.

When I link with mingw, I have a choice of DLLs to link with, including
msvcrt.dll, msvcrt4.dll, msvcr71.dll, and perhaps others - I don't even
need the DLLs on my system to link with them.

However, I cannot redistribute these DLLs when I compile with MingW
(unless I also have a copy of VS.NET - I would have to reread its
license to find out whether it requires that the application is actually
built with MSVC to allow for redistribution) .

Regards,
Martin

[Martin v. Löwis]

Re: MinGW and Python

Ross Ridge wrote:[color=blue]
> MSVCRT.DLL has been a standard system compent of Windows since at least
> Windows 98. Many other system components depend on it. Essentially,
> MSVCRT.DLL is an "undocument ed" part of the Windows API. It's not
> exactly "endorsed", Microsoft would rather you use it's current
> compiler and runtime, but it is the standard "official" Windows system
> C library.[/color]

See

http://msdn2.microsoft.com/en-us/lib...yh(VS.80).aspx

'The msvcrt.dll is now a "known DLL," meaning that it is a system
component owned and built by Windows. It is intended for future use only
by system-level components.'

The SDK stopped including an import library for it (I believe earlier
versions of the SDK still had an import library).

Regardless, there is no version of the MS C++ library that links against
msvcrt.dll. So if Python is linked against msvcrt.dll, you can't really
build C++ extensions anymore (with MSVC), unless you are certain that
mixing CRTs causes no harm for your application.

Regards,
Martin

[Martin v. Löwis]

Re: MinGW and Python

Ross Ridge wrote:[color=blue]
> Not exactly. They're both GCC, but the MinGW compiler that you can
> download from MinGW WWW site is a native Win32 appliction, while the
> "MinGW" compiler included with Cygwin and invoked by "-mno-cygwin" is a
> Cygwin application.[/color]

Any Cygwin application is a native Win32 application, which just happens
to link with cygwin1.dll (which also is a native Win32 DLL).

Just to make that clear: Everything that cygwin does is done solely with
the Win32 API. The C library differs in semantics from the MS C library,
but the system API is just the same.

Regards,
Martin

[Ross Ridge]

Re: MinGW and Python

Ross Ridge wrote:[color=blue]
> MSVCRT.DLL has been a standard system compent of Windows since at least
> Windows 98. Many other system components depend on it. Essentially,
> MSVCRT.DLL is an "undocument ed" part of the Windows API. It's not
> exactly "endorsed", Microsoft would rather you use it's current
> compiler and runtime, but it is the standard "official" Windows system
> C library.[/color]

Martin v. Löwis wrote:[color=blue]
> http://msdn2.microsoft.com/en-us/lib...yh(VS.80).aspx
>
> 'The msvcrt.dll is now a "known DLL," meaning that it is a system
> component owned and built by Windows. It is intended for future use only
> by system-level components.'[/color]

Exactly, it's the standard Windows system C library.
[color=blue]
> The SDK stopped including an import library for it (I believe earlier
> versions of the SDK still had an import library).[/color]

An import library for it is easy enough to obtain. You can make your
own, or just grab the one from MinGW. If you insist on a Microsoft
source for it then you can find it in the Windows DDK.
[color=blue]
> Regardless, there is no version of the MS C++ library that links against
> msvcrt.dll.[/color]

The version of the MS C++ library in Visual Studio C++ 6 links against
MSVCRT.DLL.
[color=blue]
> So if Python is linked against msvcrt.dll, you can't really build C++
> extensions anymore (with MSVC), unless you are certain that
> mixing CRTs causes no harm for your application.[/color]

Python 2.4 is linked against MSVCR71.DLL, so you can't really build C
or C++ extensions anymore with Microsoft's current compiler either.

Ross Ridge

[Ross Ridge]

Re: MinGW and Python

Ross Ridge wrote:[color=blue]
> Not exactly. They're both GCC, but the MinGW compiler that you can
> download from MinGW WWW site is a native Win32 appliction, while the
> "MinGW" compiler included with Cygwin and invoked by "-mno-cygwin" is a
> Cygwin application.[/color]

Martin v. Löwis wrote:[color=blue]
> Any Cygwin application is a native Win32 application, which just happens
> to link with cygwin1.dll (which also is a native Win32 DLL)[/color]

Nonetheless, Cygwin applications are not generally considered native
Win32 applications because of the dependency on CYGWIN1.DLL and the
related environment. While what you're saying a strictly true, the
term "native Win32" is used to make a distinction between a port of a
program that doesn't use or require the Cygwin environment from one
that does. For example, the official version of Python for Windows is
considered a native Win32 application because it's implemented using
the Windows APIs directly, as opposed to the Cygwin's version of Python
which implemented using Cygwin's POSIX emulation API, and only uses the
Windows API indirectly.

Ross Ridge

[Philippe Martin]

Re: MinGW and Python

This might relevant.

http://www.aceshardware.com/read.jsp?id=153

Philippe



Robert Kern wrote:
[color=blue]
> Martin v. Löwis wrote:[color=green]
>> Srijit Kumar Bhadra wrote:
>>[color=darkred]
>>>Is there any specific reason for not using MinGW to build the official
>>>distributi on of Python for Win32?[/color]
>>
>> What could be the reasons to use MinGW?
>>
>> As for reasons not to do that:
>> - there is no build process available to do that
>> - people building extensions to Python must be able to do so with
>> Microsoft C++, since some of these extensions are written using MFC.
>> - developing Python itself in Visual Studio is quite convenient; in
>> particular, the debugger works "better" than gdb.[/color]
>
> - gcc does not optimize particularly well.
>
> --
> Robert Kern
> robert.kern@gma il.com
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma
> that is made terrible by our own mad attempt to interpret it as though it
> had an underlying truth."
> -- Umberto Eco[/color]

[Martin v. Löwis]

Re: MinGW and Python

Ross Ridge wrote:[color=blue]
> Martin v. Löwis wrote:[color=green]
>> http://msdn2.microsoft.com/en-us/lib...yh(VS.80).aspx
>>
>> 'The msvcrt.dll is now a "known DLL," meaning that it is a system
>> component owned and built by Windows. It is intended for future use only
>> by system-level components.'[/color]
>
> Exactly, it's the standard Windows system C library.[/color]

That's not how I read it. To me, it says: it can be used by other
parts of Windows itself (i.e. system-level components), but it is not
intended to be used by third-party applications (such as Python),
as these are not system-level components.
[color=blue][color=green]
>> Regardless, there is no version of the MS C++ library that links against
>> msvcrt.dll.[/color]
>
> The version of the MS C++ library in Visual Studio C++ 6 links against
> MSVCRT.DLL.[/color]

I see (*). Unfortunately, that version isn't available anymore, and
wasn't available anymore when Python 2.4 was released.
[color=blue][color=green]
>> So if Python is linked against msvcrt.dll, you can't really build C++
>> extensions anymore (with MSVC), unless you are certain that
>> mixing CRTs causes no harm for your application.[/color]
>
> Python 2.4 is linked against MSVCR71.DLL, so you can't really build C
> or C++ extensions anymore with Microsoft's current compiler either.[/color]

Right: you need to use VS.NET 2003 (which was the current compiler
when Python 2.4 was first released).

Regards,
Martin

[Martin v. Löwis]

Re: MinGW and Python

Ross Ridge wrote:[color=blue]
> Nonetheless, Cygwin applications are not generally considered native
> Win32 applications because of the dependency on CYGWIN1.DLL and the
> related environment. While what you're saying a strictly true, the
> term "native Win32" is used to make a distinction between a port of a
> program that doesn't use or require the Cygwin environment from one
> that does.[/color]

I know it is common to take that view, but I believe it is wrong, no
matter how you look at it:

- Is winword.exe not a native Win32 library because it uses "MSO.DLL"?
- A cygwin application does *not* require the Cygwin environment.
You don't need to invoke it from bash.exe, you don't need
to install Cygwin to run it, and you don't need a directory structure
including /usr or /etc to make it work.
[color=blue]
> For example, the official version of Python for Windows is
> considered a native Win32 application because it's implemented using
> the Windows APIs directly[/color]

That isn't (entirely) true. Python largely doesn't use the Win32 API
directly, but instead, it uses the C library of the C compiler it
was built with. It also uses the Win32 API directly, and more so
in Python 2.5 than in earlier versions, but reliance on the C library
still hasn't been dropped.

For Py3k, perhaps the C library can be dropped entirely: Guido wants
to drop usage of stdio as an implementation of the file object; if
then malloc/free is dropped in favour of a "direct" implementation
(e.g. based on HeapAlloc), then Python could become a "native Win32
application" in the sense you defined above.

Regards,
Martin

[sturlamolden]

Re: MinGW and Python


Martin v. Löwis wrote:
[color=blue]
> That's not how I read it. To me, it says: it can be used by other
> parts of Windows itself (i.e. system-level components), but it is not
> intended to be used by third-party applications (such as Python),
> as these are not system-level components.[/color]

That is correct. And it is the reson why the MinGW team is working on
removing the dependency on this CRT. I

[sturlamolden]

Re: MinGW and Python


Martin v. Löwis wrote:

[color=blue][color=green]
> > Nonetheless, Cygwin applications are not generally considered native
> > Win32 applications because of the dependency on CYGWIN1.DLL and the
> > related environment.[/color][/color]
[color=blue]
> - Is winword.exe not a native Win32 library because it uses "MSO.DLL"?
> - A cygwin application does *not* require the Cygwin environment.[/color]

Cygwin executables are native windows ".exe files" just like MinGW
executables. They are built by the same compiler, a port of GCC to 32
bit Windows originally written by Mumit Khan. MinGW and Cygwin apps run
at the same speed. However, the CYGWIN1.dll is bloated and an has
unwanted overhead for many system calls. But as such, CYGWIN1.dll is
nothing more than a CRT with extended "Linux API" support, including
posix and xlib.

The problem is actually *licensing issues* related to CYGWIN1.DLL. It
cannot always be linked. CYGWIN1.DLL can only be used for Open Source
development.

"In accordance with section 10 of the GPL, Red Hat permits programs
whose sources are distributed under a license that complies with the
Open Source definition to be linked with libcygwin.a/cygwin1.dll
without libcygwin.a/cygwin1.dll itself causing the resulting program to
be covered by the GNU GPL."

Thus, if you have a commercial closed source application, you need to
use MinGW; that is, you cannot link with libcygwin.a/cygwin1.dll.

I am not sure if Cygwin has link libraries for the Win32 API. Is there
e.g. a libuser32.a for linking with user32.dll? But MinGW has that.

[sturlamolden]

Re: MinGW and Python


Martin v. Löwis wrote:

[color=blue][color=green]
> > Nonetheless, Cygwin applications are not generally considered native
> > Win32 applications because of the dependency on CYGWIN1.DLL and the
> > related environment.[/color][/color]
[color=blue]
> - Is winword.exe not a native Win32 library because it uses "MSO.DLL"?
> - A cygwin application does *not* require the Cygwin environment.[/color]

Cygwin executables are native windows ".exe files" just like MinGW
executables. They are built by the same compiler, a port of GCC to 32
bit Windows originally written by Mumit Khan. MinGW and Cygwin apps run
at the same speed. However, the CYGWIN1.dll is bloated and an has
unwanted overhead for many system calls. But as such, CYGWIN1.dll is
nothing more than a CRT with extended "Linux API" support, including
posix and xlib.

The problem is actually *licensing issues* related to CYGWIN1.DLL. It
cannot always be linked. CYGWIN1.DLL can only be used for Open Source
development.

"In accordance with section 10 of the GPL, Red Hat permits programs
whose sources are distributed under a license that complies with the
Open Source definition to be linked with libcygwin.a/cygwin1.dll
without libcygwin.a/cygwin1.dll itself causing the resulting program to
be covered by the GNU GPL."

Thus, if you have a commercial closed source application, you need to
use MinGW; that is, you cannot link with libcygwin.a/cygwin1.dll.

I am not sure if Cygwin has link libraries for the Win32 API. Is there
e.g. a libuser32.a for linking with user32.dll? But MinGW has that.