Martin v. Löwis wrote:
How would you build for MSVCRT.DLL using MSVC 7 or 8? You don't have
the header files for that library...
You should be able to use the header files that come with these
compilers. Things like sizes, field offsets, or member function
names don't change between versions
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
g] On Behalf Of Ross Ridge
Sent: Thursday, April 27, 2006 8:53 PM
Subject: Re: MinGW and Python
No one is working on removing MinGW's depency on MSVCRT.DLL.
There is certainly work underway to ease the use
folder.
The solution must be to get the msvcrXX dependency out of Python.
There remains one technical issue that isn't a killer but would
be inconvenient, IMHO: Can pywin32 be made working with a
mingw-python (I'm quite sure it can't be made building on it)?
I'd appreciate any datapoints
Ames Andreas wrote:
There remains one technical issue that isn't a killer but would
be inconvenient, IMHO: Can pywin32 be made working with a
mingw-python (I'm quite sure it can't be made building on it)?
I'd appreciate any datapoints about that ...
It all depends on what CRT version you
-Original Message-
From: Martin v. Löwis [mailto:[EMAIL PROTECTED]
Sent: Friday, April 28, 2006 6:20 PM
Subject: Re: MinGW and Python
It all depends on what CRT version you link Python with. If you
use mingw32 to link Python with msvcr71.dll, nothing would change
for pywin32
one technical issue that isn't a killer but would
be inconvenient, IMHO: Can pywin32 be made working with a
mingw-python (I'm quite sure it can't be made building on it)?
I don't why it couldn't. It works with old versions of Python that use
MSVCRT.DLL.
I think that having current versions
Ross Ridge wrote:
You'd have to point people who don't already have it to Microsoft's
download site.
Is there a download site? I have not been able to localise one.
I think that having current versions of Python also linked MSVCRT.DLL,
whether compiled with MinGW or MSVC 6, 7 or 8, could
Ross Ridge wrote:
You'd have to point people who don't already have it to Microsoft's
download site.
sturlamolden wrote:
Is there a download site? I have not been able to localise one.
Links where you can download them were posted in the thread you started
on the MinGW C/C++ forum.
2. you
Ross Ridge wrote:
Links where you can download them were posted in the thread you started
on the MinGW C/C++ forum.
AFAIK the links were for various versions of the VS 2005
redistributable. It does not contain msvcr71.dll, instead it has
msvcr80.dll.
I don't think there is a download for
Ross Ridge wrote:
I think that having current versions of Python also linked MSVCRT.DLL,
whether compiled with MinGW or MSVC 6, 7 or 8, could be over all be a
better solution than using a CRT DLL specific to one version of
Microsoft's compiler. It would make it possible to build extentions
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
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
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*
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*
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*
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:
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
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
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
--
http://mail.python.org/mailman/listinfo/python-list
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
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
, but your question is a non sequitur. I don't understand its
relevance to this thread.
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?
I cannot predict
Neal Becker wrote:
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
Neal Becker wrote:
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
Neal Becker [EMAIL PROTECTED] writes:
release. Since mingw is usually current, I haven't checked, but they may
be using 4.1 now.
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
Edward Elliott wrote:
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).
don't know what you mean by endorsed. does it lack features of
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
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
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
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
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
Ross Ridge wrote:
Martin v. Löwis wrote:
http://msdn2.microsoft.com/en-us/library/abx4dbyh(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
Robert Kern [EMAIL PROTECTED] writes:
the gcc project is to provide a portable compiler, not one that
generates the best code for any given platform. And in that goal, it
succeeds remarkably well.
Will a python program be slower on the same machine running windows
compared to linux?
What I
Brian Elmegaard wrote:
What I don't understand is that it is not possible to distribute a
python compiled with gcc for windows. The main reason I saw in this
thread is that python uses mfc. So python requires api access, I
guess.
You misunderstood. Python does not use MFC. PythonWin (for
Brian Elmegaard wrote:
Robert Kern [EMAIL PROTECTED] writes:
the gcc project is to provide a portable compiler, not one that
generates the best code for any given platform. And in that goal, it
succeeds remarkably well.
Will a python program be slower on the same machine running windows
Brian Elmegaard wrote
the gcc project is to provide a portable compiler, not one that
generates the best code for any given platform. And in that goal, it
succeeds remarkably well.
Will a python program be slower on the same machine running windows
compared to linux?
a better optimizer
Martin v. Löwis [EMAIL PROTECTED] writes:
It would certainly be possible to distribute a gcc-compiled python.
However, what is the point in doing so? Cygwin already includes
a gcc-compiled Python, for Windows:
Interesting.
That is simply not true.
Actually, you answered me then too. I
Robert Kern [EMAIL PROTECTED] writes:
If you meant writing extension modules for Python instead of extending
distutils,
I thought about extending distutils to make non-python installers. I
may have misunderstood the answers I got.
Fredrik Lundh [EMAIL PROTECTED] writes:
a better optimizer usually results in programs that run faster, not slower.
Got it the wrong after some editing ;-(
--
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 wrote:
- there is no build process available to do that
In MSYS:
$ ./configure --prefix=/c/mingw
$ make
$ make install
This should be obvious to any with Unix experience.
MinGW actually distribute precompiled Python binaries as well (in
MSYS-DTK).
- people building
it can handle Python as well. My guess is you
will not notice any performance difference for the Python interpreter.
Doesn't Python run well on Linux? GCC is used to build Python on Linux.
MinGW is GCC. MinGW on Windows creates the same binary code as GCC on
Linux.
--
http://mail.python.org/mailman
relevance
to this thread.
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?
--
http://mail.python.org/mailman/listinfo/python-list
I forgot to mention that C libraries built with Visual C++ and MinGW
are binary compatible. MinGW can link libararies and object files from
Visual C++. Although Python may be build with Visual C++, you can still
compile and link your C extensions with MinGW.
--
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
g] On Behalf Of sturlamolden
Sent: Tuesday, April 25, 2006 2:27 PM
Subject: Re: MinGW and Python
Robert Kern wrote:
- gcc does not optimize particularly well.
That is beyond BS. The more recent gcc
is a non sequitur. I don't understand its
relevance to this thread.
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?
I cannot predict this, though it would be great
sturlamolden [EMAIL PROTECTED] wrote:
Robert Kern wrote:
- gcc does not optimize particularly well.
That is beyond BS. The more recent gcc releases optimize as well as any
commercial compiler. GCC 4 may even optimize better than MSVC.
GCC is the compiler used to build the Linux kernel
sturlamolden wrote:
Robert Kern wrote:
- gcc does not optimize particularly well.
That is beyond BS.
The more recent gcc releases optimize as well as any
commercial compiler.
This is an outrageous claim. Having worked a bit doing
compilers, I no of no commercial compiler that would
Alex Martelli wrote:
At the same time, if the 14% slowdown is representative, then it's not
true that the compiler responsible for it optimizes as well as the
other; indeed, does not optimize particularly well, under such a
hypothesis, would be far from a beyond BS assertion.
Maybe someone
Alex Martelli wrote:
about MacOSX, which also uses gcc: 14% faster pybench using Python 2.4.3
this is the second time I've seen that 14% figure. OOC, where does it come
from? the data sets you posted show an average 12.6% speedup. 14 is an
odd way to round. :)
I don't think it's very useful
Brian Elmegaard wrote:
Martin v. Löwis [EMAIL PROTECTED] writes:
You can build the entire Python interpreter with Cygwin (but you
don't need to, because there is a precompiled version), and you can
build extensions for the python.org binary using MingW.
Great, then I tend to agree that
Edward Elliott wrote:
if so, i do see good reason to build with mingw instead of gcc/cygwin.
MinGW and Cygwin GCC is actually the same compiler. On Cygwin you can
remove the dependency on the cygwin dll by compiling with -mno-cygwin.
But as long as the cygwin dll is there, it creates an
sturlamolden wrote:
MinGW and Cygwin GCC is actually the same compiler. On Cygwin you can
remove the dependency on the cygwin dll by compiling with -mno-cygwin.
But as long as the cygwin dll is there, it creates an overhead for any
system call.
Thanks for that very informative post! To
few people use it, support for mingw keeps breaking
(inadvertently), so there might be bugs that prevent it from
working *for you*.
At the point this was written (apparently around Python 2.2)
it was possible to build Python extensions with MingW (the page
actually explains you how to do that), so
Edward Elliott wrote:
Thanks for that very informative post! To clarify, mingw (aka gcc
-mno-cygwin) has no POSIX layer like cygwin. Because your post could also
be (incorrectly) interpreted to mean mingw removes the cygwin dll
dependency by just linking it in statically. But I googled and
sturlamolden wrote:
- there is no build process available to do that
In MSYS:
$ ./configure --prefix=/c/mingw
$ make
$ make install
This should be obvious to any with Unix experience.
MinGW actually distribute precompiled Python binaries as well (in
MSYS-DTK).
So how does that
sturlamolden wrote:
MinGW and Cygwin GCC is actually the same compiler.
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
sturlamolden wrote:
MinGW can compile MFC. Download Windows Platform SDK and you get the
MFC source.
Do not do this. The Platform SDK's EULA does not permit you to
redistribute anything you build from the MFC sources included in the
SDK. The only way to get a copy of MFC that you can
Edward Elliott wrote:
Couldn't you compile the msvc-python code under gcc/mingw?
Yes I could, but I cannot compile the code under msvc for comparison. I
only have MinGW. If build the mingw binary then someone else has to
build the msvc binary for comparison. Then we could do pybenches on the
Martin v. Löwis wrote:
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).
MSVCRT.DLL has been a standard system compent of Windows since at
sturlamolden wrote:
But as long as the cygwin dll is there, it creates an overhead for any
system call. The worst overhead is associated with the Unix fork()
system call, which Cygwin must emulate as there are no Win32
equivalent. In particular, a fork() on Unix will be optimized with
sturlamolden wrote:
Edward Elliott wrote:
Couldn't you compile the msvc-python code under gcc/mingw?
Yes I could, but I cannot compile the code under msvc for comparison. I
only have MinGW. If build the mingw binary then someone else has to
build the msvc binary for comparison. Then we
Martin v. Löwis wrote:
Well, you are not compiling with neither mingw, nor cygwin; you are
compiling with gcc in either case.
touche, mr. pedant. :)
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
Ross Ridge wrote:
MSVCRT.DLL ... 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.
Does it comply with the ANSI C89 standard? I'm still not seeing why mingw
can't just link python to it.
--
Edward Elliott wrote:
Sorry, I didn't mean you personally, I meant you in the general sense.
OK :-)
I've just tried to build Python 2.4.3 with MinGW (MSYS 1.0.10, GCC
3.4.2):
$ ./configure --prefix=/c/Python243-mingw
$ make
The build then failed on posixmodule.c.
Sturla Molden
./Modules
Edward Elliott wrote:
Ross Ridge wrote:
MSVCRT.DLL ... 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.
Does it comply with the ANSI C89 standard? I'm still not seeing why mingw
can't just
sturlamolden:
Uh .. I actually think it could be an EULA violation to publish mingw
vs. msvc benchmarks without permission from Microsoft. I don't want to
part of anything illegal or have M$ lawyers breathing down my back. If
we are going to do this, then we must do it properly and get the
Martin v. Löwis wrote:
Please believe me: there is currently no build process that
gives the same results as the build process used. It might
be fairly easy to create one, but none exists as of today.
I tried to build with MinGW this eveing and it failed. I believe you We
need to make a
Look what I just found:
http://jove.prohosting.com/iwave/ipython/pyMinGW.html
A build process for python 2.4.2 (i.e. not the latest) for MinGW.
--
http://mail.python.org/mailman/listinfo/python-list
Edward Elliott [EMAIL PROTECTED] wrote:
Alex Martelli wrote:
about MacOSX, which also uses gcc: 14% faster pybench using Python 2.4.3
this is the second time I've seen that 14% figure. OOC, where does it come
from? the data sets you posted show an average 12.6% speedup. 14 is an
odd
Edward Elliott [EMAIL PROTECTED] wrote:
Alex Martelli wrote:
At the same time, if the 14% slowdown is representative, then it's not
true that the compiler responsible for it optimizes as well as the
other; indeed, does not optimize particularly well, under such a
hypothesis, would be far
Alex Martelli wrote:
I assume you mean compare pybench on Python 2.4.3 compiled under etc.
Yep
Unfortunately, I suspect the ex-officio gcc defenders will only react by
finding yet another quibble (anything to avoid admitting that gcc may
not be as good at optimizing as a _Microsoft_ product
Alex Martelli wrote:
I believe the single figure is a useful summary. Even the most
sophisticated benchmarks are eventually boiled down to single figures,
as in so many SPECmarks etc, because in everyday discourse a scalar is
what you can reasonably discuss. Sure, philosophically speaking it
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
--
http://mail.python.org/mailman/listinfo/python-list
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
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.
You may look at this thread:
* E02 - Support for MinGW Open Source Compiler
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
Robert Kern [EMAIL PROTECTED] writes:
- gcc does not optimize particularly well.
But well enough for other platforms.
--
Brian (remove the sport for mail)
http://www.et.web.mek.dtu.dk/Staff/be/be.html
http://www.rugbyklubben-speed.dk
--
http://mail.python.org/mailman/listinfo/python-list
Brian Elmegaard wrote:
Robert Kern [EMAIL PROTECTED] writes:
- gcc does not optimize particularly well.
But well enough for other platforms.
Well, it tends to optimize just as poorly for other platforms, too. It's just
frequently the only compiler widely available on those platforms. The
78 matches
Mail list logo
