Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
in [Python]
|
Prev: Python GUI for C program [was: ]
Next: Download Microsoft C/C++ compiler for use with Python 2.6/2.7ASAP
From: Zooko O'Whielacronx on 25 Jul 2010 14:07 On Wed, Jul 7, 2010 at 3:32 AM, Jonathan Hartley <tartley(a)tartley.com> wrote: > > I presume this problem would go away if future versions of Python > itself were compiled on Windows with something like MinGW gcc. You might want to track issue3871. Roumen Petrov has done a lot of work to make CPython compilable with mingw on Windows, as well as to make it possible to compile CPython on a different operating system and produce a CPython executable for Windows (cross-compile). And by the way, I've usually had success building my native extension modules with mingw. I understand (vaguely) that if a native extension module needs to pass FILE*'s or C++ iostreams back and forth to different extension modules or the the core CPython interpreter then this could lead to segfaults, but none of my extension modules need to do that. I would suggest that people try to build their native extension modules with mingw, and if it doesn't work report a bug (to mingw project and to the Python project) so that we can track more precisely what the issues are. Regards, Zooko http://bugs.python.org/issue3871# cross and native build of python for mingw32 with distutils
From: David Cournapeau on 25 Jul 2010 18:05 On Mon, Jul 26, 2010 at 3:07 AM, Zooko O'Whielacronx <zooko(a)zooko.com> wrote: > > I would suggest that people try to build their native extension > modules with mingw, and if it doesn't work report a bug (to mingw > project and to the Python project) so that we can track more precisely > what the issues are. To be clear, building extensions with mingw for the official python works well. Numpy and scipy official binaries have been built with mingw for years. There are problems for 64 bits binaries, though David
From: Burton Samograd on 26 Jul 2010 11:47 Grant Edwards <invalid(a)invalid.invalid> writes: > On 2010-07-24, Lawrence D'Oliveiro <ldo(a)geek-central.gen.new_zealand> wrote: >> In message <mailman.323.1278440923.1673.python-list(a)python.org>, Robert Kern >> wrote: >> >>> There are also utilities for mounting ISOs directly without burning >>> them to a physical disk. >> >> You need special utilities to do this?? > > Not if the OS and VFS are competently designed. In Linux all you need > to do is this: > > mount -o loop /path/to/file.iso /mount/point > > Apparently you've got to jump through all sorts of hoops using 3rd > party software to do something analgous in MS Windows. In Windows you use DaemonTools. -- Burton Samograd
From: Robin Becker on 26 Jul 2010 11:57 On 26/07/2010 16:47, Burton Samograd wrote: > Grant Edwards<invalid(a)invalid.invalid> writes: > >> On 2010-07-24, Lawrence D'Oliveiro<ldo(a)geek-central.gen.new_zealand> wrote: >>> In message<mailman.323.1278440923.1673.python-list(a)python.org>, Robert Kern >>> wrote: >>> >>>> There are also utilities for mounting ISOs directly without burning >>>> them to a physical disk. >>> >>> You need special utilities to do this?? >> >> Not if the OS and VFS are competently designed. In Linux all you need >> to do is this: >> >> mount -o loop /path/to/file.iso /mount/point >> >> Apparently you've got to jump through all sorts of hoops using 3rd >> party software to do something analgous in MS Windows. > > In Windows you use DaemonTools. > > -- > Burton Samograd > I use VCdControlTool.exe which is some kind of M$ utility, but perhaps that doesn't work for everyone. -- Robin Becker
From: Jean-Michel Pichavant on 29 Jul 2010 05:43
Robert Kern wrote: > On 7/23/10 7:08 PM, Lawrence D'Oliveiro wrote: >> In message<mailman.323.1278440923.1673.python-list(a)python.org>, >> Robert Kern >> wrote: >> >>> There are also utilities for mounting ISOs directly without burning >>> them >>> to a physical disk. >> >> You need special utilities to do this?? > > On at least some versions of Windows, Yes. > You need the "mount" utility with Linux. JM |