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 versio
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:
> 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:
> 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. yo
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, coul
Ross Ridge write:
> 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:
> -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.
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
Ames Andreas wrote:
> 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
> -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
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
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
C
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
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.
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
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.
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
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
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
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
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
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.'
>
> Exactl
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 reaso
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 applica
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 ap
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
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 fea
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
http://www.
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
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
Alex Martelli wrote:
> sturlamolden <[EMAIL PROTECTED]> 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.
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 speaki
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_ pro
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
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
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
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 bu
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
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 mi
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
./Modul
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 i
"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.d
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 w
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
> cop
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
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
s
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 legiti
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 applica
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 d
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 a
Brian Elmegaard wrote:
>> 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
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 c
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 overhe
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 agr
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
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 s
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 wou
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 Li
sturlamolden <[EMAIL PROTECTED]> 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 que
> -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 we
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.
--
http://mail.python.org/mailman/lis
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
> rel
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
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 extens
"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
--
http://mail.py
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.
http://groups.google.com/group/comp.lang.python/browse_thre
"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
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 op
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 w
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
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
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.
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
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
> -
> 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
ht
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 mu
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
78 matches
Mail list logo
