MinGW and Python
Srijit Kumar Bhadra
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"
> 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.
Regards,
Martin
Josef Meile
* E02 - Support for MinGW Open Source Compiler
http://tinyurl.com/lxfsz
There was a big polemic and it is really long, but there are some useful
posts there.
Regards,
Josef
Robert Kern
- gcc does not optimize particularly well.
--
Robert Kern
rober...@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
Brian Elmegaard
> - 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
Robert Kern
> Robert Kern <rober...@gmail.com> 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 goal of
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.
Brian Elmegaard
> 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 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.
Once I asked about distutils here. The answer was that I had access to
the source so I could just extend it. After messing around I found I
couldn't because I don't have msvc.
"Martin v. Löwis"
> 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 example)
does. That has a lot of implications which are hard to understand
if you are not familiar with Windows programming and the C library
mess on Windows.
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:
http://cygwin.com/packages/python/
> Once I asked about distutils here. The answer was that I had access to
> the source so I could just extend it. After messing around I found I
> couldn't because I don't have msvc.
That is simply not true. 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.
Regards,
Martin
Robert Kern
> Robert Kern <rober...@gmail.com> 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?
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.
> 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.
It is possible. People have done it.
http://jove.prohosting.com/iwave/ipython/pyMinGW.html
> Once I asked about distutils here.
Okay. Again, what's the relevance here?
> The answer was that I had access to
> the source so I could just extend it. After messing around I found I
> couldn't because I don't have msvc.
I'm not sure why this matters since distutils is pure Python.
If you meant writing extension modules for Python instead of extending
distutils, then you're in luck! You can indeed build extension modules with
mingw for the standard Python distribution. Please see my post in the thread "MS
VC++ Toolkit 2003, where?".
Fredrik Lundh
> > 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 usually results in programs that run faster, not slower.
</F>
Brian Elmegaard
> 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 misunderstood after reading
http://sebsauvage.net/python/mingw.html.
Is the information on that page not correct? Has it never been?
> 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 there is no reason for building it
with mingw.
Brian Elmegaard
> 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.
http://groups.google.com/group/comp.lang.python/browse_thread/thread/3f721b5a38fbc2d1/7af1aea19aa187b6?lnk=st&q=author%3Aelmegaard+distutils&rnum=1#7af1aea19aa187b6
> mingw for the standard Python distribution. Please see my post in the thread "MS
> VC++ Toolkit 2003, where?".
Thanks, I will.
Brian Elmegaard
> a better optimizer usually results in programs that run faster, not slower.
Got it the wrong after some editing ;-(
sturlamolden
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 extensions to Python must be able to do so with
> Microsoft C++, since some of these extensions are written using MFC.
MinGW can compile MFC. Download Windows Platform SDK and you get the
MFC source.
> - developing Python itself in Visual Studio is quite convenient; in
> particular, the debugger works "better" than gdb.
Eclipse is an excellent IDE that works with MinGW.
sturlamolden
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 and MacOSX. If it
can deal with this I say 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.
sturlamolden
Robert Kern wrote:
> 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.
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?
sturlamolden
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.
Ames Andreas
> From: python-list-bounces+andreas.ames=comer...@python.org
> [mailto:python-list-bounces+andreas.ames=comer...@python.or
> 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 releases optimize as
> well as any
> commercial compiler. GCC 4 may even optimize better than MSVC.
Not to talk of standard compliance (msvc-c99 anyone?).
cheers,
aa
--
Andreas Ames | Programmer | Comergo GmbH |
Voice: +49 69 7505 3213 | ames AT avaya . com
Alex Martelli
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
Alex Martelli
> 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 and MacOSX. If it
> can deal with this I say it can handle Python as well. My guess is you
> will not notice any performance difference for the Python interpreter.
That is quite possible, of course: if, for example, the 14% speed
difference I measured with pybench is representative, then you might not
notice it because human beings have a hard time noticing time
differences of that magnitude. But it might still be there, easy to
measure, even though not to notice.
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.
Alex
Scott David Daniels
> 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 have
a leg to stand on if it claimed it optimized "as well as
any commercial compiler."
There are compilers and compiler experts out there in the
weeds that can (and regularly do) compile the hell out of code.
I took classes from one of these guys, and now he works in a
little company that does exactly that for particular customers
and problems.
Uncle Timmy, used to work for some of the places that employed
some of these experts. There is no "fully optimized state" for
compiled code (if the resultant instruction stream is greater
than a few hundred instructions); everyone approximates optimization.
It is almost inevitably a grey trade-off of compile time to speed
of resulting code over certain distributions of problems.
To say "gcc does a credible job of optimization" would not be
outrageous. To say "gcc optimization beats tool X on benchmark Y
on hardware Z by 1.237%" is a claim that could be made supportably,
but it would probably have to be accompanied with "using optimization
switches gcc-W for gcc and X-W for tool X."
I expect gcc does a reasonably good job of optimization, but the
best optimizers (as far as I know) are done by a relatively small
number of people who fully understand the workings of the optimizer
and its current workload, the workings of the hardware in question
as well, and have chosen a portion of that workload to become expert
in. Gcc does not have that expertise available to support people
to do things like that (nor does it need to). They don't need (or
want) to become wed to one architecture, but to do the best optimization
you must at some point get married.
The gcc team does a great job at what they do; blind defense of them
discredits the good work they do.
--Scott David Daniels
scott....@acm.org
Edward Elliott
> 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 with access to Windows and some free time could compare
pybench compiled under msvc and mingw. The best way to test the compiler
is to eliminate all other variables.
Edward Elliott
> 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 to talk about average speedups from a
benchmark of equally-weighted feature tests. the data shows wildly varying
differences in performance for each test. a real-world application could
be much slower or much faster on either platform depending on its feature
mix. not the type of thing that's amenable to expression as a single
value.
Edward Elliott
> "Martin v. Löwis" <mar...@v.loewis.de> 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 there is no reason for building it
> with mingw.
wouldn't the gcc/cygwin build of python rely on the cygwin dll? cygwin
implements the standard unix system calls on top of the windows platform.
iirc, some operations run much slower through cygwin than native windows
calls (file and terminal i/o come to mind).
if so, i do see good reason to build with mingw instead of gcc/cygwin.
sturlamolden
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 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
copy-on-write semantics in the kernel, but Cygwin cannot emulate that
as it has no access to the Windows kernel.
Another issue is that MinGW and Cygwin implements C++ exceptions with
setjmp/longjmp. Other verions of GCC (including DJGPP for DOS) does not
do this and as a result produces faster code for C++. I don't know if
there are any C++ in Python, but if there is, it will be an issue. it
is not an issue for plain C though.
Finally, MinGW (I am not sure about Cygwin) statically links the C++
standard library. VC++ and GCC on other platforms (e.g. Linux) does not
(normally) do this, and as a result the executables get a smaller
footprint.
Edward Elliott
> 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 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 this is not
the case.
Back to the original point about whether mingw compilation is necessary
given the python compiles under cygwin: Yes, it is. There can't be an
apples-to-apples comparison between gcc and msvc-compiled python with the
cygwin POSIX layer in the way.
Couldn't you compile the msvc-python code under gcc/mingw? If the code
sticks to C standards, and mingw can link to native libs, it should work.
The only problem is if python relies on some msvc-specific weirdness under
msvc. While there's much weirdness in msvc, I would expect a
cross-platform app like python to stay away from it.
"Martin v. Löwis"
>> That is simply not true.
>
> Actually, you answered me then too. I misunderstood after reading
> http://sebsauvage.net/python/mingw.html.
>
> Is the information on that page not correct? Has it never been?
It's not correct, to the best of my knowledge. However, since
very 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 "Under Windows, if you
do not have the costly Microsoft Visual C++, you cannot
install Python extensions written in C" wasn't even true
at the time it was written. You couldn't use distutils, but
you could certainly have built extensions by invoking the
compiler manually.
There were times when cygwin couldn't link with .DLLs unless
they were created with GNU ld, but these times are long past
history.
Regards,
Martin
"Martin v. Löwis"
> 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 this is not
> the case.
Well, you are not compiling with neither mingw, nor cygwin; you are
compiling with gcc in either case.
The question is what C library (and header files) you use: with cygwin,
you use cygwin1.dll (and its header files); with mingw, you use
msvcrt.dll (or some other MS CRT), along with the a GNU version of the
Microsoft header files.
> Couldn't you compile the msvc-python code under gcc/mingw? If the code
> sticks to C standards, and mingw can link to native libs, it should work.
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).
> The only problem is if python relies on some msvc-specific weirdness under
> msvc. While there's much weirdness in msvc, I would expect a
> cross-platform app like python to stay away from it.
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. So Python itself never uses and msvcrt weirdness (well,
some, but that could be dropped easily) - yet still, the Python
binary will depend on a specific version of the MS CRT.
Regards,
Martin
"Martin v. Löwis"
>> - 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 deal with the various extension modules that
PCbuild/readme.txt mentions? Do I get winsound.pyd? _msi.pyd
(in 2.5)?
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.
>> - people building extensions to Python must be able to do so with
>> Microsoft C++, since some of these extensions are written using MFC.
>
> MinGW can compile MFC. Download Windows Platform SDK and you get the
> MFC source.
Did you actually try that? Last I tried, GCC would refuse to compile
the MinGW header files.
Even if you succeed, I don't think the SDK license will allow you
to distribute your binary, and it *will* be incompatible the official
MFC binary. MSVC++ has its own object layout, vtable layout, name
mangling, so you can't use GCC to link against MSVC-compiled
C++ libraries.
Regards,
Martin
Ross Ridge
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 application.
Ross Ridge
Ross Ridge
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 legitimately use
in anything you distribute you need to buy a Microsoft C++ compiler.
Ross Ridge
sturlamolden
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
same computer.
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
permissions we need.
Ross Ridge
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 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.
Ross Ridge
sjde...@yahoo.com
> 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
> copy-on-write semantics in the kernel, but Cygwin cannot emulate that
> as it has no access to the Windows kernel.
Cygwin doesn't do COW fork() for historical reasons. Windows 95/98
didn't expose support for such a thing, but NT, XP, etc do (pass NULL
as the SectionHandle parameter to ZwCreateProcess or the older
NtCreateProcess to do a COW duplicate of the calling process).
Cygwin at one point had a fork() implementation using this in the
development tree (or being discussed on the mailing lists) but decided
not to use it since it wasn't much faster than full-copy fork for some
reason, and it would've split the code for NT/95.
Edward Elliott
> 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
> same computer.
Sorry, I didn't mean you personally, I meant "you" in the general sense.
> 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
> permissions we need.
Why, because of a "no benchmarks" clause in the EULA? First, I'm fairly
certain that clause is uneforceable. Second, it's not worth MS's time to
come after you. Third, even if they did, they'd have an incredibly tough
time showing that any harm occured from your actions, leaving them with no
recovery. Fourth, if it somehow came to that, you'd have organizations
like the EFF lining up at your door to take the case gratis. I'm assuming
US law here.
Not saying you should do it, just that the risk in my opinion is extremely
low. I am a law student, but this is not legal advice.
Edward Elliott
> 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
> and msvcrt.dll, but these aren't "endorsed" system C libraries).
don't know what you mean by "endorsed". does it lack features of the C89
ANSI standard?
> 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.
That would be a problem then. So what happens when you compile python with
msvc, and why can't mingw just replicate that?
Edward Elliott
> 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.
sturlamolden
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/posixmodule.c:308: warning: function declaration isn't a
prototype
./Modules/posixmodule.c: In function `posix_ttyname':
./Modules/posixmodule.c:1162: warning: implicit declaration of function
`ttyname'
./Modules/posixmodule.c:1162: warning: assignment makes pointer from
integer without a cast
./Modules/posixmodule.c: In function `posix_mkdir':
./Modules/posixmodule.c:1791: error: too many arguments to function
`mkdir'
./Modules/posixmodule.c: In function `posix_execv':
./Modules/posixmodule.c:2199: warning: passing arg 2 of `execv' from
incompatible pointer type
./Modules/posixmodule.c: In function `posix_execve':
./Modules/posixmodule.c:2332: warning: passing arg 2 of `execve' from
incompatible pointer type
./Modules/posixmodule.c:2332: warning: passing arg 3 of `execve' from
incompatible pointer type
./Modules/posixmodule.c: In function `posix_fork':
./Modules/posixmodule.c:2847: warning: implicit declaration of function
`fork'
./Modules/posixmodule.c: In function `posix_openpty':
./Modules/posixmodule.c:2909: error: `O_NOCTTY' undeclared (first use
in this function)
./Modules/posixmodule.c:2909: error: (Each undeclared identifier is
reported only once
./Modules/posixmodule.c:2909: error: for each function it appears in.)
./Modules/posixmodule.c:2912: error: `SIGCHLD' undeclared (first use in
this function)
./Modules/posixmodule.c:2914: warning: implicit declaration of function
`grantpt'
./Modules/posixmodule.c:2919: warning: implicit declaration of function
`unlockpt'
./Modules/posixmodule.c:2924: warning: implicit declaration of function
`ptsname'
./Modules/posixmodule.c:2924: warning: assignment makes pointer from
integer without a cast
./Modules/posixmodule.c:2931: warning: implicit declaration of function
`ioctl'
./Modules/posixmodule.c:2931: error: `I_PUSH' undeclared (first use in
this function)
./Modules/posixmodule.c: In function `posix_getegid':
./Modules/posixmodule.c:2973: warning: implicit declaration of function
`getegid'
./Modules/posixmodule.c: In function `posix_geteuid':
./Modules/posixmodule.c:2986: warning: implicit declaration of function
`geteuid'
./Modules/posixmodule.c: In function `posix_getgid':
./Modules/posixmodule.c:2999: warning: implicit declaration of function
`getgid'
./Modules/posixmodule.c: In function `posix_getppid':
./Modules/posixmodule.c:3121: warning: implicit declaration of function
`getppid'
./Modules/posixmodule.c: In function `posix_getuid':
./Modules/posixmodule.c:3163: warning: implicit declaration of function
`getuid'
./Modules/posixmodule.c: In function `posix_kill':
./Modules/posixmodule.c:3193: warning: implicit declaration of function
`kill'
./Modules/posixmodule.c: In function `posix_wait':
./Modules/posixmodule.c:4970: warning: implicit declaration of function
`wait'
./Modules/posixmodule.c: In function `posix_pipe':
./Modules/posixmodule.c:5511: warning: implicit declaration of function
`pipe'
./Modules/posixmodule.c: At top level:
./Modules/posixmodule.c:382: warning: 'posix_error_with_filename'
defined but not used
./Modules/posixmodule.c:534: warning: 'posix_fildes' defined but not
used
./Modules/posixmodule.c:6223: warning: 'conv_confname' defined but not
used
./Modules/posixmodule.c:7126: warning: 'setup_confname_table' defined
but not used
make: *** [Modules/posixmodule.o] Error 1
Neil Hodgson
> 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
> permissions we need.
The EULA attempted to stop disclosing benchmarks of .NET code, not
C++ code. The most recent version of the EULA has replaced that with
permission to disclose benchmarks of .NET code provided some conditions
are met: full disclosure of benchmark code and environment; latest
release of .NET; compliance with 'best practices'. Its still stupid as
it would be in Microsoft's interest to encourage benchmarking .NET but
not quite as stupid as before.
Neil
sturlamolden
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 build process for MinGW.
Robert Kern
It can.
--
Robert Kern
rober...@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
sturlamolden
http://jove.prohosting.com/iwave/ipython/pyMinGW.html
A build process for python 2.4.2 (i.e. not the latest) for MinGW.
Alex Martelli
> 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 believe 12.6% is the result if you pick the faster speed as a
denominator (and so it's the right figure for a _slowdown_,
hypothetically moving from fast to slow case), 14% if you pick the
slower speed as a denominator (i.e., for a _speedup_).
Of course if you work with times rather than speeds it's the other way
around.
> I don't think it's very useful to talk about average speedups from a
> benchmark of equally-weighted feature tests. the data shows wildly varying
> differences in performance for each test. a real-world application could
> be much slower or much faster on either platform depending on its feature
> mix. not the type of thing that's amenable to expression as a single
> value.
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
makes no sense to say that a compiler is better or worse than another at
optimization, without adding a lawyer's brief worth of qualifications
each and every time. In real life, it's a useful and practical
temporary simplification, and engineers (as opposed to mathematicians
and philosophers) have a bias towards practical usefulness.
Alex
Alex Martelli
I assume you mean "compare pybench on Python 2.4.3 compiled under" etc.
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 -- perish the
thought!), therefore I'm disinclined to invest my scarce free time in
that particular endeavour.
Alex
Edward Elliott
> 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 -- perish the
> thought!), therefore I'm disinclined to invest my scarce free time in
> that particular endeavour.
No problem. I don't expect anyone to follow through, it was more a
suggestion to forestall rampant speculation. :)
Edward Elliott
> 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
> makes no sense to say that a compiler is better or worse than another at
> optimization, without adding a lawyer's brief worth of qualifications
hey is that a shot at me? ;)
> each and every time. In real life, it's a useful and practical
> temporary simplification, and engineers (as opposed to mathematicians
> and philosophers) have a bias towards practical usefulness.
I agree for benchmarks in general. It's more this particular benchmark I
object to as not being representative. It's like the difference between
SPECmark testing various CPU functions and Winstone measuring real-world
application performance. If you're a CPU designer counting coup, SPECmark
matters. For just about everyone else, Winstone tells you more. And when
you're talking about small (less than an order of magnitude) differences in
SPECmark, platform/system/application issues becomes the dominant factor in
performance. A CPU that's twice as fast won't help my i/o-bound server.
From an engineering standpoint, the pybench number isn't that useful to me.
It tells me little about the practical speed of my application on two
different python interpreters. That's all I'm saying. No need to sic the
philosophers on me (a fate I would not wish on my worst enemy). :)
Neal Becker
> sturlamolden <sturla...@yahoo.no> wrote:
>
>> Robert Kern wrote:
>>
>> > 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.
>>
>> 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 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
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
>> 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.
> 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.
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
>> 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.
> 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.
what part of
Brian Elmegaard
> 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
http://www.rugbyklubben-speed.dk
"Martin v. Löwis"
>> 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 the C89
> ANSI standard?
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/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.'
>> 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.
>
> That would be a problem then. So what happens when you compile python with
> msvc, and why can't mingw just replicate that?
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"
> 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/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.'
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"
> 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
> 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/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 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
> 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
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.
"Martin v. Löwis"
> 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 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"
> 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.
Gerhard Häring
> [...] The problem is actually *licensing issues* related to CYGWIN1.DLL. It
> cannot always be linked. CYGWIN1.DLL can only be used for Open Source
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
> 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
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.aspx?scid=kb;en-us;326922
Ross Ridge
> 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/default.asp?url=/library/en-us/dnvc60/html/redistribvc6.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.aspx?scid=kb;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
Ames Andreas
> From: python-list-bounces+andreas.ames=comer...@python.org
> [mailto:python-list-bounces+andreas.ames=comer...@python.or
> 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 of msvcrXX in
mingw built binaries. It's already possible to do it today
with some tweaking, but I seem to remember that this was already
mentioned in this thread.
For example:
http://sourceforge.net/mailarchive/message.php?msg_id=7374474
I don't think it is a technical problem that prevents a
mingw-python from being distributed, I rather see (in no
particular order):
1) psychological issues: 'convenient IDE', 'better debugger'
2) legal issues: redistribution of msvcrXX
3) 'economical' issues: no one seems to be willing to reliably
support a mingw-python
No. 2 could be a show-stopper.
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 ...
cheers,
aa
--
Andreas Ames | Programmer | Comergo GmbH |
Voice: +49 69 7505 3213 | ames AT avaya . com
sturlamolden
> 1) psychological issues: 'convenient IDE', 'better debugger'
I prefer Eclipse when using MinGW. That IDE is on par with Visual
Studio. And Python will be developed for GCC anyway.
> 2) legal issues: redistribution of msvcrXX
That is indeed the problem. msvcrXX cannot be redistributed with MinGW
binaries. On the other hand, msvcrXX cannot be redistributed with
py2exe standalones either. The current dependency on msvcrXX makes it
illegal (mostly) to distribute standalone applications made with
py2exe. You have to rely on msvcrXX already being installed in a
system 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 about that ...
Two issues:
1. COM. MinGW is not know to be the best compiler for COM development.
Although MinGW binaries are COM ABI compatible.
2. MFC. A MinGW compiled MFC cannot be legally redistributed.
"Martin v. Löwis"
> 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 link Python with. If you
use mingw32 to link Python with msvcr71.dll, nothing would change
for pywin32 compared to Python 2.4. OTOH, nothing would change
for anybody else, either.
If you link Python with msvcrt.dll, you would need to build
pywin32 with a version of MFC that also links with msvcrt.dll.
I understand VC6 would work; not sure whether pywin32 can still
be built with VC6. In any case, requiring an even older version
of the MS compiler isn't such a tempting idea, either.
Regards,
Martin
"Martin v. Löwis"
> 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 link Python with. If you
Ames Andreas
> From: "Martin v. Löwis" [mailto:mar...@v.loewis.de]
> Sent: Friday, April 28, 2006 6:20 PM
> Subject: Re: MinGW and Python
>
> use mingw32 to link Python with msvcr71.dll, nothing would change
> for pywin32 compared to Python 2.4. OTOH, nothing would change
> for anybody else, either.
I'm more concerned that it might expose some C++ code (symbols)
to other python code but I haven't looked at pywin32's implementation
so I can't really tell. If it does, one shouldn't use it with _any_
compiler other than the one used to build pywin32. Even a mix of
different ms-compilers would be dangerous, IMHO.
Ross Ridge
> No one is working on removing MinGW's depency on MSVCRT.DLL.
Ames Andreas wrote:
> There is certainly work underway to ease the use of msvcrXX in
> mingw built binaries.
Danny makes it pretty clear in the message you refered that he's not
working on that.
> 2) legal issues: redistribution of msvcrXX
...
> No. 2 could be a show-stopper.
You'd have to point people who don't already have it to Microsoft's
download site. This wouldn't be ideal, but then Python already points
Windows users to Microsoft's download site if they don't have MSI
already installed.
> 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 don't why it couldn't. It works with old versions of Python that use
MSVCRT.DLL.
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
with any version of MSVC, instead of just the one that Python was built
with.
Ross Ridge
sturlamolden
> 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 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
> with any version of MSVC, instead of just the one that Python was built
> with.
I am not sure it is good enough. For two reasons:
1. msvcrt.dll is intended for future use by system level components
only.
2. you need an import library for msvcrt.dll, if your VS don't ship
with one you are lost.
What is the difference between msvcrt.dll and msvcr71.dll?
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. An application should use and
redistribute msvcr71.dll, and it should avoid placing a copy or using
an existing copy of msvcr71.dll in the system directory. Instead, the
application should keep a copy of msvcr71.dll in its application
directory with the program executable. Any application built with
Visual C++ .NET using the /MD switch will necessarily use msvcr71.dll.
Ross Ridge
> 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 need an import library for msvcrt.dll, if your VS don't ship
> with one you are lost.
I already listed in this thread other alternatives for legitimately
obtaining an MSVCRT.DLL import library.
Ross Ridge
sturlamolden
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 msvcr71.dll.
"Martin v. Löwis"
> 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
> with any version of MSVC, instead of just the one that Python was built
> with.
How would you build for MSVCRT.DLL using MSVC 7 or 8? You don't have
the header files for that library, and you don't have the import
library.
Regards,
Martin
Ross Ridge
Martin v. Löwis wrote:
> How would you build for MSVCRT.DLL using MSVC 7 or 8? You don't have
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 of the runtime. See the MSDN
library page you refered to earlier:
http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx
>... and you don't have the import library.
I already mentioned where you can get it.
Ross Ridge