MinGW and Python

[Srijit Kumar Bhadra]

Is there any specific reason for not using MinGW to build the official
distribution of Python for Win32?
A quick Google search did not reveal the answer to my question. If a
link is available, please post it.

Best Regards,
Srijit

[Martin v. Löwis]

Ross Ridge wrote:

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 "undocumented" 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.

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]

Ross Ridge wrote:

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.

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]

Ross Ridge wrote:

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 "undocumented" 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.
Martin v. Löwis wrote: 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.'
Exactly, it's the standard Windows system C library.
The SDK stopped including an import library for it (I believe earlier
versions of the SDK still had an import library).
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.
Regardless, there is no version of the MS C++ library that links against
msvcrt.dll.
The version of the MS C++ library in Visual Studio C++ 6 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.

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]

Ross Ridge wrote:

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.
Martin v. Löwis wrote: Any Cygwin application is a native Win32 application, which just happens
to link with cygwin1.dll (which also is a native Win32 DLL)

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]

This might relevant.

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

Philippe

Robert Kern wrote:

Martin v. Löwis wrote:

Srijit Kumar Bhadra wrote:

Is there any specific reason for not using MinGW to build the official
distribution of Python for Win32?

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.

- gcc does not optimize particularly well.

--
Robert Kern
ro*********@gmail.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

[Martin v. Löwis]

Ross Ridge wrote:

Martin v. Löwis wrote:

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.'

Exactly, it's the standard Windows system C library.

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.

Regardless, there is no version of the MS C++ library that links against
msvcrt.dll.

The version of the MS C++ library in Visual Studio C++ 6 links against
MSVCRT.DLL.

I see (*). Unfortunately, that version isn't available anymore, and
wasn't available anymore when Python 2.4 was released.

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.

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.

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]

Ross Ridge wrote:

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.
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.
For example, the official version of Python for Windows is
considered a native Win32 application because it's implemented using
the Windows APIs directly

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]

Martin v. Löwis wrote:

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.

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

[sturlamolden]

Martin v. Löwis wrote:

Nonetheless, Cygwin applications are not generally considered native
Win32 applications because of the dependency on CYGWIN1.DLL and the
related environment.

- Is winword.exe not a native Win32 library because it uses "MSO.DLL"?
- A cygwin application does *not* require the Cygwin environment.

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]

Martin v. Löwis wrote:

Nonetheless, Cygwin applications are not generally considered native
Win32 applications because of the dependency on CYGWIN1.DLL and the
related environment.

- Is winword.exe not a native Win32 library because it uses "MSO.DLL"?
- A cygwin application does *not* require the Cygwin environment.

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]

Martin v. Löwis wrote:

Nonetheless, Cygwin applications are not generally considered native
Win32 applications because of the dependency on CYGWIN1.DLL and the
related environment.

- Is winword.exe not a native Win32 library because it uses "MSO.DLL"?
- A cygwin application does *not* require the Cygwin environment.

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.

[Gerhard Häring]

sturlamolden wrote:

[...] 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. [...]

Of course Redhat offers an alternative license that does not have the
GPL restrictions: http://www.redhat.com/software/cygwin/

Like other annoying companies, they don't tell any rates at their
website and make you call them up if you're interested. Cowards.

-- Gerhard

[Ross Ridge]

Ross Ridge wrote:

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.
Martin v. Löwis wrote: I know it is common to take that view, but I believe it is wrong, no
matter how you look at it

Regardless, that's what "native Win32 application" means in this
context, and makes a useful and well understood distinction between
ports.

Ross Ridge

[Ross Ridge]

sturlamolden wrote:

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.

No, Cygwin executables are built using a different port of GCC, the
Cygwin port of GCC. The two ports are very similar, but the Cygwin
port is a Cygwin application. That means, for example, it uses Cygwin
pathnames instead of the standard Win32 pathnames that MinGW uses.

Ross Ridge

[Ross Ridge]

sturlamolden wrote:

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

No one is working on removing MinGW's depency on MSVCRT.DLL.

Ross Ridge

[sturlamolden]

I seem to vaguely remember that MinGW was going to get its own CRT. And
unless it does, MinGW is a defect compiler for legal resons. It cannot
be legally used.

Microsoft has designated the CRT that MinGW links a system file,
against which no application should link. Insted they have asked that a
CRT is distributed together with any program that depends on it. If you
program needs msvcrt.dll, you should redistribute msvcrt.dll and place
a copy in your program's install directory.

When you compile with MinGW, you are not allowed to to that. Microsof's
CRTs can only be distributed with programs that are compiled with
Microsoft's compilers. Even if you hold a license for Visual Studio,
you are still not permitted to redistribute the CRT if you compiled
your program with MinGW.

http://support.microsoft.com/default...b;en-us;326922

[Ross Ridge]

sturlamolden wrote:

I seem to vaguely remember that MinGW was going to get its own CRT. And
unless it does, MinGW is a defect compiler for legal resons. It cannot
be legally used.
That is simply not true.
Microsoft has designated the CRT that MinGW links a system file,
against which no application should link.
While they may not recommend it anymore, Microsoft no more prohibits
applications linking against MSVCRT.DLL than KERNEL32.DLL.
Insted they have asked that a CRT is distributed together
with any program that depends on it. If you program needs
msvcrt.dll, you should redistribute msvcrt.dll and place
a copy in your program's install directory.
No, this is not how Microsoft recommends installing MSVCRT.DLL.
Because it is a system DLL it should be, after doing appropriate
version checking, installed in the system directory. See:

http://msdn.microsoft.com/library/de...distribvc6.asp
When you compile with MinGW, you are not allowed to to that.
That's why MinGW applications don't include MSVCRT.DLL in their
distributions. There's no reason to do so, since it's installed
already on virtually all Windows systems. Even on systems like Windows
95 where MSVCRT.DLL wasn't originally a system DLL, it's usually
already been installed as a consequence of installing some other
application.
http://support.microsoft.com/default...b;en-us;326922

This article describes how MSVCR70.DLL, MSVCR71.DLL and MSVCR80.DLL
should be installed. Since these DLLs, as the article points out,
aren't system files they should differently than MSVCRT.DLL.

Ross Ridge