Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
Jean-Michel Pichavant wrote: Robert Kern wrote: On 7/23/10 7:08 PM, Lawrence D'Oliveiro wrote: In message, 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 On Windows see Daemon-tools lite. free, easy, no spyware. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
Robert Kern wrote: On 7/23/10 7:08 PM, Lawrence D'Oliveiro wrote: In message, 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 26/07/2010 16:47, Burton Samograd wrote: Grant Edwards writes: On 2010-07-24, Lawrence D'Oliveiro wrote: In message, 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
Grant Edwards writes: > On 2010-07-24, Lawrence D'Oliveiro wrote: >> In message , 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On Mon, Jul 26, 2010 at 3:07 AM, Zooko O'Whielacronx 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On Wed, Jul 7, 2010 at 3:32 AM, Jonathan Hartley 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 2010-07-24, Lawrence D'Oliveiro wrote: > In message , 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. -- Grant -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 7/23/10 7:08 PM, Lawrence D'Oliveiro wrote: In message, 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. -- Robert Kern "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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
In message , 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?? -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 9 Jul, 02:02, Neil Hodgson wrote: > If you break the rules by using malloc rather than IMalloc for memory > that is deallocated by a different component to that which allocated it > or try to pass around FILE* objects then you will see failures. Yes, the CRT issue applies to COM as well. COM developers are even less aware of this than Python developers. > So, > always follow the COM rules. Or just avoid COM... -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
Dave Angel wrote: >Tim Roberts wrote: >> >> No. The multi-thread-aware CRT in Visual C++ (which is the only option >> since VS2008) puts errno in thread-local storage, so it's shared by all >> CRTs. >> >I didn't know specifically that errno is in TLS, but I will disagree >with the conclusion that a TLS entry is implicitly shared by all CRT's. >Unless the CRT for each DLL explicitly does some extra work to allow >sharing, each will have its own set of TLS variables. Yes, I should have thought about this before posting. I checked the CRT source code, and you are correct. Every DLL that calls the C run-time startup code will do its own TlsAlloc. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
Tim Roberts wrote: Christian Heimes wrote: Yeah, but then we're down to file descriptors, C library locales and such as the remaining problems. Don't forget errno! Every CRT might have its own errno thread local. I don't know how its handled on Windows but I suspect it suffers from the same problem. No. The multi-thread-aware CRT in Visual C++ (which is the only option since VS2008) puts errno in thread-local storage, so it's shared by all CRTs. I didn't know specifically that errno is in TLS, but I will disagree with the conclusion that a TLS entry is implicitly shared by all CRT's. Unless the CRT for each DLL explicitly does some extra work to allow sharing, each will have its own set of TLS variables. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
Christian Heimes wrote: >> Yeah, but then we're down to file descriptors, C library locales and such as >> the >> remaining problems. > >Don't forget errno! Every CRT might have its own errno thread local. I >don't know how its handled on Windows but I suspect it suffers from the >same problem. No. The multi-thread-aware CRT in Visual C++ (which is the only option since VS2008) puts errno in thread-local storage, so it's shared by all CRTs. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
sturlamolden: > Windows did this too (msvcrt.dll) up to the VS2003 release, which came > with msvcr71.dll in addition. Since then, M$ (pronounced Megadollar > Corp.) have published msvcr80.dll, msvcr90.dll, and msvcr100.dll (and > corresponding C++ versions) to annoy C and C++ developers into > converting to C# .NET. (And yes, programs using third-party DLL and > OCX components become unstable from this. You have to check each DLL/ > OCX you use, and each DLL used by each DLL, etc. How fun...) One of the benefits to COM is that it acts as a C runtime firewall - it has its own memory allocation interface (IMalloc / CoGetMalloc) and file I/O is performed through interfaces like IStream. It is quite common to use an OCX compiled with one compiler in an application compiled with another. If you break the rules by using malloc rather than IMalloc for memory that is deallocated by a different component to that which allocated it or try to pass around FILE* objects then you will see failures. So, always follow the COM rules. Neil -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
> Really? I wasn't entirely aware of this effect of the "io" module. > Somehow, without at all paying attention (because certain third party > modules blocking me for awhile, I never looked close enough), I just > sort of thought the "io" module was mostly thin wrappers around stdio > primitives, into a more Pythonic API. Yes, really. :) The new io modules doesn't use stdio. It operates solely on file descriptors and low level functions like open(2) instead of fopen(3). All high level functions like buffering is implemented in Python (and some C for speed). Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 7/7/10 9:46 PM, "Martin v. Löwis" wrote: >> I saw you already mentioned work toward this a few months (years ?) >> ago. Is there some kind of roadmap, or could you use some help ? I >> would really like to solve this issue as much as we possibly can, > > Well, Python 3 has already dropped stdio for its own io library, and > I do want to get rid of the remaining FILE* usage for 3.2. Any other > change needs to be discussed on python-dev first; contributions are welcome. Really? I wasn't entirely aware of this effect of the "io" module. Somehow, without at all paying attention (because certain third party modules blocking me for awhile, I never looked close enough), I just sort of thought the "io" module was mostly thin wrappers around stdio primitives, into a more Pythonic API. This actually makes me long for Python 3 more. And adjust agendas to push my day-job work to 2.7 as soon as possible, and start a preemptive reconfiguration to support a future Py3k migration. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
> I saw you already mentioned work toward this a few months (years ?) > ago. Is there some kind of roadmap, or could you use some help ? I > would really like to solve this issue as much as we possibly can, Well, Python 3 has already dropped stdio for its own io library, and I do want to get rid of the remaining FILE* usage for 3.2. Any other change needs to be discussed on python-dev first; contributions are welcome. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On Wed, Jul 7, 2010 at 9:10 PM, Martin v. Loewis wrote: > > My preferred long-term solution is to reduce the usage of the C library > in CPython as much as reasonable, atleast on Windows. Memory management > could directly use the heap functions (or even more directly > VirtualAlloc); filenos could be OS handles, and so on. There are > probably limitations to what you can achieve, but I think it's worth trying. I saw you already mentioned work toward this a few months (years ?) ago. Is there some kind of roadmap, or could you use some help ? I would really like to solve this issue as much as we possibly can, David -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 8 Jul, 00:35, Jonathan Hartley wrote: > I see. Thanks very much to both of you for the info, much appreciated. The problem you referred to for py2exe despaired with Python 2.6. For Python 2.5, there was no public download option for msvcr71.dll and msvcp71.dll. There was also the unsolved SxS issue. Thus a license for Visual Studio 2003 was required to distribute py2exe apps for Python 2.5. That is now history. For py2exe apps using Python 2.6, 2.7 or 3.1, you can just ask your clients to install this: http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en http://www.microsoft.com/downloads/details.aspx?familyid=BA9257CA-337F-4B40-8C14-157CFDFFEE4E&displaylang=en There are similar downloads for Visual C++ 2010 run-time files as well. Python 3.2 will probably be built with Visual Studio 2010. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On Jul 7, 8:22 pm, "Martin v. Loewis" wrote: > > I presume this problem would go away if future versions of Python > > itself were compiled on Windows with something like MinGW gcc. Also, > > this would solve the pain of Python developers attempting to > > redistribute py2exe versions of their programs (i.e. they have to own > > a Visual Studio license to legally be able to redistribute the > > required C runtime) I don't understand enough to know why Visual > > Studio was chosen instead of MinGW. Can anyone shed any light on that > > decision? > > sturlamolden has already given the primary reason: Python, > traditionally, attempts to use and work with the system vendor's > compiler. On Windows, that's MSC. It's typically the one that best knows > about platform details that other compilers might be unaware of. > > In addition, it's also the compiler and IDE that Windows developers (not > just Python core people, but also extension developers and embedders) > prefer to use, as it has quite good IDE support (in particular debugging > and code browsing). > > Perhaps more importantly, none of the other compilers is really an > alternative. GCC in particular cannot build the Win32 extensions, since > it doesn't support the COM and ATL C++ features that they rely on (and > may not support other MSC extensions, either). So the Win32 extensions > must be built with VS, which means Python itself needs to use the same > compiler. > > Likewise important: gcc/mingw is *not* a complete C compiler on Windows. > A complete C compiler would have to include a CRT (on Windows); mingw > doesn't (cygwin does, but I think you weren't proposing that Python be > built for cygwin - you can easily get cygwin Python anyway). Instead, > mingw relies on users having a CRT available to > them - and this will be a Microsoft one. So even if gcc was used, we > would have versioning issues with Microsoft CRTs, plus we would have to > rely on target systems including the right CRT, as we couldn't include > it in the distribution. > > HTH, > Martin I see. Thanks very much to both of you for the info, much appreciated. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 7 Jul, 23:19, "Alf P. Steinbach /Usenet" wrote: > D Linking the CRT dynamically and providing an optional download and > install of the redistributables if they're not present. This would > best be done with some support from the Python installation machinery. > -> Small nice size for extensions, still same CRT state problems. This was a problem for py2exe'd apps before Python 2.6 (i.e. no public download for Visual C++ 2003 runtime files.) But for Visual C++ 2008 and 2010, the CRTs can be downloaded from Microsoft and need not be shipped with the application. http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en http://www.microsoft.com/downloads/details.aspx?familyid=BA9257CA-337F-4B40-8C14-157CFDFFEE4E&displaylang=en http://www.microsoft.com/downloads/details.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84&displaylang=en http://www.microsoft.com/downloads/details.aspx?familyid=BD512D9E-43C8-4655-81BF-9350143D5867&displaylang=en -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
Am 07.07.2010 23:49, schrieb sturlamolden: > On 7 Jul, 23:33, "Martin v. Loewis" wrote: > >>> The Windows API "errno" is GetLastError. But a delinquent CRT might >>> map GetLastError() to other integers. >> >> Please check the source before posting. msvcrt defines errno as > > I don't have the source to msvcrt, at least not to my knowledge. If you have Visual Studio, and opted to install the CRT sources, you'll find them in VC/crt/src (or VC7/crt/src, depending on VS version). I'm not 100% sure whether they are included in VS Express as well. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 7 Jul, 23:33, "Martin v. Loewis" wrote: > > The Windows API "errno" is GetLastError. But a delinquent CRT might > > map GetLastError() to other integers. > > Please check the source before posting. msvcrt defines errno as I don't have the source to msvcrt, at least not to my knowledge. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
* Alf P. Steinbach /Usenet, on 07.07.2010 23:19: However developing an extension with MSVC 10 the extension will use the 10.0 CRT, which is not necessarily present on the end user's system. As I see it there are five solutions with different trade-offs: A Already having Visual Studio 2008 (MSVC 9.0), or coughing up the money for an MSDN subscription, or visiting trade shows, so as to obtain that compiler version. -> Not an option for everybody. B Linking the CRT statically. -> Increased size, problems with CRT state such as file descriptors. C Linking the CRT dynamically and bundling the MSVC redistributables with the extension. -> Even more increased size for the download, but smaller total footprint for extensions in sum; same CRT state problems. D Linking the CRT dynamically and providing an optional download and install of the redistributables if they're not present. This would best be done with some support from the Python installation machinery. -> Small nice size for extensions, still same CRT state problems. E As D + a new compiler-independent native code interface that does not carry dependencies on CRT state such as file descriptors, like JNI. -> Really huge effort, and cannot be applied until some new Python version. And I think the clue here is that the CRT state problems can be avoided by careful coding. Hence, for those who cannot do A I think B is a realistic practical option, and D would be nice... Wait... F Possibly, as the docs say, "Developer Studio will throw in a lot of import libraries that you do not really need, adding about 100K to your executable. To get rid of them, use the Project Settings dialog, Link tab, to specify ignore default libraries. Add the correct msvcrtxx.lib to the list of libraries." Can anyone confirm whether this works in practice with MSVC 10? Cheers, - Alf -- blog at http://alfps.wordpress.com> -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
Am 07.07.2010 22:35, schrieb sturlamolden: > On 7 Jul, 22:26, Christian Heimes wrote: > >> Don't forget errno! Every CRT might have its own errno thread local. I >> don't know how its handled on Windows but I suspect it suffers from the >> same problem. > > The Windows API "errno" is GetLastError. But a delinquent CRT might > map GetLastError() to other integers. Please check the source before posting. msvcrt defines errno as _CRTIMP extern int * __cdecl _errno(void); #define errno (*_errno()) where _errno is (see dosmap.c) int * __cdecl _errno(void) { _ptiddata ptd = _getptd_noexit(); if (!ptd) { return &ErrnoNoMem; } else { return ( &ptd->_terrno ); } } where _getptd_noexit returns the CRT's per-thread data (see tidtable.c). So it *is* a mapping to other integers, and, even though it's called dosmap.c, it is maintained because of the (limited) POSIX support in the CRT. In particular, there is a mapping between GetLastError values and errno values that can't be implemented through simple defines (e.g. both ERROR_FILE_NOT_FOUND and ERROR_PATH_NOT_FOUND map to ENOENT). In addition, a standard C implementation can rely on only certain APIs changing errno, which MS perhaps might not be able to guarantee for GetLastError values in exactly the same manner. So with the way the Windows API is defined, a C implementation has no alternative but to be delinquent. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
* Christian Heimes, on 07.07.2010 22:47: The main problem that the required MSVC redistributables are not necessarily present on the end user's system. It's not a problem for Python anymore. It took a while to sort all problems out. Martin and other developers have successfully figured out how to install the CRT for system wide and local user installations. A system wide installation installs the CRT in the side by side cache (WinSxS). A local installation keeps the msvcrt90.dll and the Microsoft.VC90.CRT.manifest next to the python.exe. Python extensions no longer embed a manifest so they share the CRT from the python.exe process. In order to ship a standalone exe you have to keep the CRT next to your exe. This should work for py2exe binaries as well. At our company we install our application stack entirely from subversion including Python 2.6.5, Sun JRE and lots of other stuff. This works perfectly fine for us even for servers without the MSVCRT redistributable. I think you're talking about a different problem. The CRT installed along with CPython works for extensions using the MSVC 9.0 CRT. However developing an extension with MSVC 10 the extension will use the 10.0 CRT, which is not necessarily present on the end user's system. As I see it there are five solutions with different trade-offs: A Already having Visual Studio 2008 (MSVC 9.0), or coughing up the money for an MSDN subscription, or visiting trade shows, so as to obtain that compiler version. -> Not an option for everybody. B Linking the CRT statically. -> Increased size, problems with CRT state such as file descriptors. C Linking the CRT dynamically and bundling the MSVC redistributables with the extension. -> Even more increased size for the download, but smaller total footprint for extensions in sum; same CRT state problems. D Linking the CRT dynamically and providing an optional download and install of the redistributables if they're not present. This would best be done with some support from the Python installation machinery. -> Small nice size for extensions, still same CRT state problems. E As D + a new compiler-independent native code interface that does not carry dependencies on CRT state such as file descriptors, like JNI. -> Really huge effort, and cannot be applied until some new Python version. And I think the clue here is that the CRT state problems can be avoided by careful coding. Hence, for those who cannot do A I think B is a realistic practical option, and D would be nice... Cheers, - Alf -- blog at http://alfps.wordpress.com> -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
> The main problem that the required MSVC redistributables are not necessarily > present on the end user's system. It's not a problem for Python anymore. It took a while to sort all problems out. Martin and other developers have successfully figured out how to install the CRT for system wide and local user installations. A system wide installation installs the CRT in the side by side cache (WinSxS). A local installation keeps the msvcrt90.dll and the Microsoft.VC90.CRT.manifest next to the python.exe. Python extensions no longer embed a manifest so they share the CRT from the python.exe process. In order to ship a standalone exe you have to keep the CRT next to your exe. This should work for py2exe binaries as well. At our company we install our application stack entirely from subversion including Python 2.6.5, Sun JRE and lots of other stuff. This works perfectly fine for us even for servers without the MSVCRT redistributable. Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 7 Jul, 22:26, Christian Heimes wrote: > Don't forget errno! Every CRT might have its own errno thread local. I > don't know how its handled on Windows but I suspect it suffers from the > same problem. The Windows API "errno" is GetLastError. But a delinquent CRT might map GetLastError() to other integers. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
> Yeah, but then we're down to file descriptors, C library locales and such as > the > remaining problems. Don't forget errno! Every CRT might have its own errno thread local. I don't know how its handled on Windows but I suspect it suffers from the same problem. Christia -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 2010-07-07, Martin v. Loewis wrote: > >> Also observe that this macro is very badly written (even illegal) C. >> Consider what this would do: >> >> PyMem_MALLOC(n++) >> >> According to Linus Thorvalds using macros like this is not even legal >> C: >> >> http://www.linuxfocus.org/common/src/January2004_linus.html > > [Please don't use "legal" wrt. programs - it's not "illegal" to violate > the language's rules; you don't go to jail when doing so. Linus said > "not allowed"] Nonsense. The world "illegal" doesn't mean "you'll go to jail". "Legal" and "illegal" are used to indicate conformance or nonconformace with respect to some set of rules -- be they a programming language standard, FIFA footbal rules, or Forumula 1 technical regulations. It's perfectly standard usage to refer to an "illegal forward pass" in American football, to "illegal tires" used during a race, or to an "illegal operation" in a program. -- Grant Edwards grant.b.edwardsYow! I feel like I'm at in a Toilet Bowl with a gmail.comthumbtack in my forehead!! -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 7 Jul, 21:47, "Martin v. Loewis" wrote: > However, the C standard is silent wrt. to PyMem_MALLOC, and it certainly > allows the definition of macros which use the macro arguments more than > once. Ok, I knew there was something odd here. PyMem_Malloc is indeed a function, whilst PyMem_MALLOC is a deprecated macro. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
* Martin v. Loewis, on 07.07.2010 21:56: Perhaps (if it isn't intentional) this is a bug of the oversight type, that nobody remembered to update the macro? Update in what way? I was guessing that at one time there was no PyMem_Malloc. And that it was introduced to fix Windows-specific problems, but inadvertently without updating the macro. It's just a guess as to reasons why the macro uses malloc directly. It might indeed be that the function version was introduced specifically for Windows. However, the macro was left intentionally: both for backwards compatibility, and for use inside Python itself. Except for the problems with file descriptors I think a practical interim solution for extensions implemented in C could be to just link the runtime lib statically. [...] When I wrote "link the runtime lib statically" that was an alternative to the usual link-as-DLL. Ok, I lost the thread. When you said "a practical interim solution" you were talking about what problem? I thought the discussion was about the need to link with the same DLL version as Python. The main problem that the required MSVC redistributables are not necessarily present on the end user's system. It wouldn't make sense to link the runtime lib statically as an alternative to linking it statically. However, it would surely make sense to link with a different DLL than the one that Python links with, assuming that would actually work. As for linking to a different /version/ of the CRT, if you really mean that, I think that's difficult. It's not necessarily impossible, after all there's STLPort. But I think that it must at the very least be rather difficult to do with Microsoft's tools, for otherwise people would have employed that solution before, and so I wouldn't trust the result, and wouldn't waste the time trying. It's actually straight-forward (or used to be, until they came up with the SxS madness). It was actually the case that people did so unexpectingly, and it seemed to work fine, except that it crashed when passing FILE*. Then we started explaining that mixing CRTs is risky. Oh. Well then. :-) Cheers, - Alf -- blog at http://alfps.wordpress.com> -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
* sturlamolden, on 07.07.2010 21:46: On 7 Jul, 21:41, "Alf P. Steinbach /Usenet" wrote: You still have two CRTs linked into the same process. So? CRT resources cannot be shared across CRT borders. That is the problem. Multiple CRTs are not a problem if CRT resources are never shared. Yeah, but then we're down to file descriptors, C library locales and such as the remaining problems. Cheers, - Alf -- blog at http://alfps.wordpress.com> -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
>>> Perhaps (if it isn't intentional) this is a bug of the oversight type, >>> that nobody remembered to update the macro? >> >> Update in what way? > > I was guessing that at one time there was no PyMem_Malloc. And that it > was introduced to fix Windows-specific problems, but inadvertently > without updating the macro. It's just a guess as to reasons why the > macro uses malloc directly. It might indeed be that the function version was introduced specifically for Windows. However, the macro was left intentionally: both for backwards compatibility, and for use inside Python itself. >>> Except for the problems with file descriptors I think a practical >>> interim solution for extensions implemented in C could be to just link >>> the runtime lib statically. [...] > > When I wrote "link the runtime lib statically" that was an alternative > to the usual link-as-DLL. Ok, I lost the thread. When you said "a practical interim solution" you were talking about what problem? I thought the discussion was about the need to link with the same DLL version as Python. > It wouldn't make sense to link the runtime lib statically as an > alternative to linking it statically. However, it would surely make sense to link with a different DLL than the one that Python links with, assuming that would actually work. > As for linking to a different /version/ of the CRT, if you really mean > that, I think that's difficult. It's not necessarily impossible, after > all there's STLPort. But I think that it must at the very least be > rather difficult to do with Microsoft's tools, for otherwise people > would have employed that solution before, and so I wouldn't trust the > result, and wouldn't waste the time trying. It's actually straight-forward (or used to be, until they came up with the SxS madness). It was actually the case that people did so unexpectingly, and it seemed to work fine, except that it crashed when passing FILE*. Then we started explaining that mixing CRTs is risky. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 7 Jul, 21:47, "Martin v. Loewis" wrote: > That would partially defeat the purpose, namely it would require the > compiler to put the size into a variable in memory, and possibly prevent > optimizations from taking place that rely on constant propagation > (depending on how smart the compiler is). Also after reading carefully what Linus said, it would still be incorrect if n is a complex expression. So, an inline function is the "correct" one here. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
> Also observe that this macro is very badly written (even illegal) C. > Consider what this would do: > > PyMem_MALLOC(n++) > > According to Linus Thorvalds using macros like this is not even legal > C: > > http://www.linuxfocus.org/common/src/January2004_linus.html [Please don't use "legal" wrt. programs - it's not "illegal" to violate the language's rules; you don't go to jail when doing so. Linus said "not allowed"] You are misinterpreting that statement. Linus said that the isdigit macro was non-conforming, *and meant that specifically for isdigit()*. That's because the C standard says that isdigit is a function. Under the as-if rule, you may implement it as a macro as long as nobody can tell the difference. However, in the presented implementation, there is a notable difference. However, the C standard is silent wrt. to PyMem_MALLOC, and it certainly allows the definition of macros which use the macro arguments more than once. > This would be ok, and safe as long as we use the GIL: The macro is ok as it stands (minus the issues with multiple heaps). The Python convention is that you clearly recognize PyMem_MALLOC as a macro, so you should know not to pass parameters with side effects. > register Py_ssize_t __pymem_malloc_tmp; > #define PyMem_MALLOC(n)\ > (__pymem_malloc_tmp = n, (((__pymem_malloc_tmp) < 0 || > (__pymem_malloc_tmp) > PY_SSIZE_T_MAX) ? NULL \ > : malloc((__pymem_malloc_tmp) ? > (__pymem_malloc_tmp) : 1))) That would partially defeat the purpose, namely it would require the compiler to put the size into a variable in memory, and possibly prevent optimizations from taking place that rely on constant propagation (depending on how smart the compiler is). Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 7 Jul, 21:41, "Alf P. Steinbach /Usenet" wrote: > > You still have two CRTs linked into the same process. > > So? CRT resources cannot be shared across CRT borders. That is the problem. Multiple CRTs are not a problem if CRT resources are never shared. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
* sturlamolden, on 07.07.2010 21:12: On 7 Jul, 06:54, "Alf P. Steinbach /Usenet" wrote: PyAPI_FUNC(void *) PyMem_Malloc(size_t); #define PyMem_MALLOC(n) (((n)< 0 || (n)> PY_SSIZE_T_MAX) ? NULL \ : malloc((n) ? (n) : 1)) I was afraid of that :( Except for the problems with file descriptors I think a practical interim solution for extensions implemented in C could be to just link the runtime lib statically. You still have two CRTs linked into the same process. So? Cheers, - Alf -- blog at http://alfps.wordpress.com> -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
* Martin v. Loewis, on 07.07.2010 21:10: Python 3.1.1, file [pymem.h]: PyAPI_FUNC(void *) PyMem_Malloc(size_t); #define PyMem_MALLOC(n)(((n)< 0 || (n)> PY_SSIZE_T_MAX) ? NULL \ : malloc((n) ? (n) : 1)) The problem with the latter that it seems that it's intended for safety but does the opposite... Why do you say that? It certainly *does* achieve safety, wrt. to certain errors, specifically: - passing sizes that are out-of-range - supporting malloc(0) on all systems It uses malloc instead of PyMem_Malloc. malloc may well be different and use a different heap in an extension DLL than in the Python interpreter and other extensions. That's one thing that the docs (rightly) warn you about. Perhaps (if it isn't intentional) this is a bug of the oversight type, that nobody remembered to update the macro? Update in what way? I was guessing that at one time there was no PyMem_Malloc. And that it was introduced to fix Windows-specific problems, but inadvertently without updating the macro. It's just a guess as to reasons why the macro uses malloc directly. Except for the problems with file descriptors I think a practical interim solution for extensions implemented in C could be to just link the runtime lib statically. For a minimal extension this increased the size from 8 KiB to 49 KiB. And generally with MS tools the size is acceptably small. If you think that's fine for your extension module (which may well be the case), go ahead. I have no comment on that except pointing it out as a somewhat stupid, somewhat evil social inclusion/exclusion argument, talking to the audience. Argh. You're wasting my time. But anyway, 49 KiB is small by today's standards. For example, you get 20 of those in a single MiB, and about 20.000 in a single GiB. But then, you could also just link with a different DLL version of the CRT instead. When I wrote "link the runtime lib statically" that was an alternative to the usual link-as-DLL. It wouldn't make sense to link the runtime lib statically as an alternative to linking it statically. As for linking to a different /version/ of the CRT, if you really mean that, I think that's difficult. It's not necessarily impossible, after all there's STLPort. But I think that it must at the very least be rather difficult to do with Microsoft's tools, for otherwise people would have employed that solution before, and so I wouldn't trust the result, and wouldn't waste the time trying. Cheers, - Alf -- blog at http://alfps.wordpress.com> -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 7 Jul, 21:12, sturlamolden wrote: > > #define PyMem_MALLOC(n) (((n) < 0 || (n) > PY_SSIZE_T_MAX) ? NULL \ > > : malloc((n) ? (n) : 1)) > > I was afraid of that :( Also observe that this macro is very badly written (even illegal) C. Consider what this would do: PyMem_MALLOC(n++) According to Linus Thorvalds using macros like this is not even legal C: http://www.linuxfocus.org/common/src/January2004_linus.html This would be ok, and safe as long as we use the GIL: register Py_ssize_t __pymem_malloc_tmp; #define PyMem_MALLOC(n)\ (__pymem_malloc_tmp = n, (((__pymem_malloc_tmp) < 0 || (__pymem_malloc_tmp) > PY_SSIZE_T_MAX) ? NULL \ : malloc((__pymem_malloc_tmp) ? (__pymem_malloc_tmp) : 1))) An inline function is a better solution, but not ANSI C standard: inline void *PyMem_MALLOC(Py_ssize_t n) { return (((n) < 0 || (n) > PY_SSIZE_T_MAX) ? NULL : malloc((n) ? (n) : 1)); } -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
> I presume this problem would go away if future versions of Python > itself were compiled on Windows with something like MinGW gcc. Also, > this would solve the pain of Python developers attempting to > redistribute py2exe versions of their programs (i.e. they have to own > a Visual Studio license to legally be able to redistribute the > required C runtime) I don't understand enough to know why Visual > Studio was chosen instead of MinGW. Can anyone shed any light on that > decision? sturlamolden has already given the primary reason: Python, traditionally, attempts to use and work with the system vendor's compiler. On Windows, that's MSC. It's typically the one that best knows about platform details that other compilers might be unaware of. In addition, it's also the compiler and IDE that Windows developers (not just Python core people, but also extension developers and embedders) prefer to use, as it has quite good IDE support (in particular debugging and code browsing). Perhaps more importantly, none of the other compilers is really an alternative. GCC in particular cannot build the Win32 extensions, since it doesn't support the COM and ATL C++ features that they rely on (and may not support other MSC extensions, either). So the Win32 extensions must be built with VS, which means Python itself needs to use the same compiler. Likewise important: gcc/mingw is *not* a complete C compiler on Windows. A complete C compiler would have to include a CRT (on Windows); mingw doesn't (cygwin does, but I think you weren't proposing that Python be built for cygwin - you can easily get cygwin Python anyway). Instead, mingw relies on users having a CRT available to them - and this will be a Microsoft one. So even if gcc was used, we would have versioning issues with Microsoft CRTs, plus we would have to rely on target systems including the right CRT, as we couldn't include it in the distribution. HTH, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 7 Jul, 06:54, "Alf P. Steinbach /Usenet" wrote: > PyAPI_FUNC(void *) PyMem_Malloc(size_t); > > #define PyMem_MALLOC(n) (((n) < 0 || (n) > PY_SSIZE_T_MAX) ? NULL \ > : malloc((n) ? (n) : 1)) I was afraid of that :( > Except for the problems with file descriptors I think a practical interim > solution for extensions implemented in C could be to just link the runtime lib > statically. You still have two CRTs linked into the same process. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
> Python 3.1.1, file [pymem.h]: > > PyAPI_FUNC(void *) PyMem_Malloc(size_t); > > #define PyMem_MALLOC(n)(((n) < 0 || (n) > PY_SSIZE_T_MAX) ? NULL \ > : malloc((n) ? (n) : 1)) > > The problem with the latter that it seems that it's intended for safety > but does the opposite... Why do you say that? It certainly *does* achieve safety, wrt. to certain errors, specifically: - passing sizes that are out-of-range - supporting malloc(0) on all systems > Perhaps (if it isn't intentional) this is a bug of the oversight type, > that nobody remembered to update the macro? Update in what way? > Except for the problems with file descriptors I think a practical > interim solution for extensions implemented in C could be to just link > the runtime lib statically. For a minimal extension this increased the > size from 8 KiB to 49 KiB. And generally with MS tools the size is > acceptably small. If you think that's fine for your extension module (which may well be the case), go ahead. But then, you could also just link with a different DLL version of the CRT instead. > I think that this would be safe because since the C API has to access > things in the interpreter I think it's a given that all the relevant > functions delegate to shared library (DLL) implementations, but I have > not checked the source code. There are certainly more cases than the ones mentioned so far, in particular the time zone and the locale. The CRT carries global variables for these, so if you set them in the copy of the CRT that Python links with, you won't see the change in your extension module - which may or may not be a problem. > As a more longterm solution, perhaps python.org could make available the > redistributables for various MSVC versions, and then one could introduce > some scheme for indicating the runtime lib dependencies of any given > extension. My preferred long-term solution is to reduce the usage of the C library in CPython as much as reasonable, atleast on Windows. Memory management could directly use the heap functions (or even more directly VirtualAlloc); filenos could be OS handles, and so on. There are probably limitations to what you can achieve, but I think it's worth trying. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 7 Jul, 11:32, Jonathan Hartley wrote: > Also, > this would solve the pain of Python developers attempting to > redistribute py2exe versions of their programs (i.e. they have to own > a Visual Studio license to legally be able to redistribute the > required C runtime) http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en If this is not sufficient, ask Microsoft for permission or buy a copy of Visual Studio (any will do, you can rebuild Python). I don't understand enough to know why Visual > Studio was chosen instead of MinGW. Can anyone shed any light on that > decision? It the standard C and C++ compiler on Windows. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On Jul 6, 4:50 pm, sturlamolden wrote: > Just a little reminder: > > Microsoft has withdrawn VS2008 in favor of VS2010. The express version > is also unavailable for download. >:(( > > We can still get a VC++ 2008 compiler required to build extensions for > the official Python 2.6 and 2.7 binary installers here (Windows 7 SDK > for .NET 3.5 SP1): > > http://www.microsoft.com/downloads/details.aspx?familyid=71DEB800-C59... > > Download today, before it goes away! > > Microsoft has now published a download for Windows 7 SDK for .NET 4. > It has the VC++ 2010 compiler. It can be a matter of days before the VC > ++ 2008 compiler is totally unavailable. I presume this problem would go away if future versions of Python itself were compiled on Windows with something like MinGW gcc. Also, this would solve the pain of Python developers attempting to redistribute py2exe versions of their programs (i.e. they have to own a Visual Studio license to legally be able to redistribute the required C runtime) I don't understand enough to know why Visual Studio was chosen instead of MinGW. Can anyone shed any light on that decision? Many thanks Jonathan Hartley -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 7/6/10 11:21 PM, Tim Roberts wrote: > sturlamolden wrote: >> >> Just a little reminder: >> >> Microsoft has withdrawn VS2008 in favor of VS2010. > > Nonsense. They have released VS2010, but they certainly have not > "withdrawn" VS2008, and I have heard of no plans to do so. Its not nonsense; Microsoft has historically made unavailable fairly quickly previous versions of the suite after a new release is out. There hasn't been any serious notification of this before it happens. The concern here is not at all without precedent. There has been some very real pain for Python extension authors/maintainers directly related to what compilers and SDK's Microsoft makes available: generally, Python is 'behind' the times of what's the latest version of VS and their SDK that is available. >> The express version is also unavailable for download. >:(( > > Also nonsense. Get it from right here: > http://www.microsoft.com/express/downloads/ > > Note the three tabs: VS2010, SQL Server R2, and VS2008. Again, not nonsense. That's available now. However, very real experience has made certain people *very* reasonably cautious about when "now" becomes "the past" in this situation: what is available now may change as soon as tomorrow or later with very little real notice. Yeah, you can get a MSDN subscription and get access to a lot. Lots of people can't afford that just to compile an extension they support. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
sturlamolden wrote: > >Just a little reminder: > >Microsoft has withdrawn VS2008 in favor of VS2010. Nonsense. They have released VS2010, but they certainly have not "withdrawn" VS2008, and I have heard of no plans to do so. >The express version is also unavailable for download. >:(( Also nonsense. Get it from right here: http://www.microsoft.com/express/downloads/ Note the three tabs: VS2010, SQL Server R2, and VS2008. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
* sturlamolden, on 06.07.2010 19:35: On 6 Jul, 19:09, Thomas Jollans wrote: Okay, you need to be careful with FILE*s. But malloc and free? You'd normally only alloc& free something within the same module, using the same functions (ie not mixing PyMem_Malloc and malloc), would you not? You have to be sure PyMem_Malloc is not an preprocessor alias for malloc (I haven't chaecked). Python 3.1.1, file [pymem.h]: PyAPI_FUNC(void *) PyMem_Malloc(size_t); #define PyMem_MALLOC(n) (((n) < 0 || (n) > PY_SSIZE_T_MAX) ? NULL \ : malloc((n) ? (n) : 1)) The problem with the latter that it seems that it's intended for safety but does the opposite... Perhaps (if it isn't intentional) this is a bug of the oversight type, that nobody remembered to update the macro? *** Except for the problems with file descriptors I think a practical interim solution for extensions implemented in C could be to just link the runtime lib statically. For a minimal extension this increased the size from 8 KiB to 49 KiB. And generally with MS tools the size is acceptably small. I think that this would be safe because since the C API has to access things in the interpreter I think it's a given that all the relevant functions delegate to shared library (DLL) implementations, but I have not checked the source code. As a more longterm solution, perhaps python.org could make available the redistributables for various MSVC versions, and then one could introduce some scheme for indicating the runtime lib dependencies of any given extension. Then when installing an extension the installer (distutils package functionality) could just check whether the required runtime is present, and if not give the user the choice of automatically downloading from python.org, or perhaps direct from Microsoft. This scheme would support dependencies on new runtime lib versions not yet conceived when the user's version of Python was installed. Cheers, - Alf -- blog at http://alfps.wordpress.com> -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On Wed, Jul 7, 2010 at 12:26 AM, Thomas Jollans wrote: > On 07/07/2010 12:08 AM, David Cournapeau wrote: >> On Tue, Jul 6, 2010 at 6:00 PM, Alf P. Steinbach /Usenet >> wrote: >>> There is no *technical* problem creating a compiler-independent C/C++ >>> language binding. >> >> It is quite hard, though, or would require changes in the API to be >> entirely safe. When I asked the question a few months ago to see if we >> could fix those issues once and for all for numpy, the most common >> answer I got was to pass all the related functions in a structure: >> http://stackoverflow.com/questions/1052491/c-runtime-objects-dll-boundaries. >> >> The problem is not compiler, but really C runtimes. By itself, the >> issues are not windows specific (using malloc from one C library and >> one free from another one is trouble everywhere), but on windows: >> - multiple C runtimes are *very* common on windows > > I'm also rather sure that it's pretty much impossible to have multiple C > libraries in one process on UNIX, but it's obviously quite possible on > Windows. I am not sure why you think it is not possible. It is rare, though. > >> - many things which are runtime independent on unix are not on >> windows (file descriptor: AFAIK, a file descriptor as returned from >> open can be dealt with in any C runtime on unix) > > Are you telling me that file descriptors (it's a flippin int!) can't be > passed around universally on Windows?? Yes. The reason why it does not work on windows is because file descriptor are not "native": in every unix I have heard of, file descriptor are indexes in a table of the process "structure", hence can be shared freely (no dependency on the C runtime structures). On windows, I have heard they are emulated (the native one is the win32 file handle). David -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 07/07/2010 01:14 AM, sturlamolden wrote: > On 7 Jul, 01:07, Thomas Jollans wrote: > >> It's not managed code in the "runs on .net" sense, but in principle, it >> is managed, in that garbage collection is managed for you. > > I think you are confusing Python and C code. Or somebody's confusing something anyway I meant "CPython based", which, in hindsight, might have not have been clear from the grammatically obfuscated sentence I posted. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 7 Jul, 01:07, Thomas Jollans wrote: > It's not managed code in the "runs on .net" sense, but in principle, it > is managed, in that garbage collection is managed for you. I think you are confusing Python and C code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 07/07/2010 12:38 AM, Martin v. Loewis wrote: >>> - many things which are runtime independent on unix are not on >>> windows (file descriptor: AFAIK, a file descriptor as returned from >>> open can be dealt with in any C runtime on unix) >> >> Are you telling me that file descriptors (it's a flippin int!) can't be >> passed around universally on Windows?? > > There are really three things of concern here: > a) operating system file handles, of type HANDLE (which is an unsigned >32-bit value); they are not contiguous, and stdin/stdout/stderr may >have arbitrary numbers > b) C runtime file handles, of type int. They are contiguous, and >stdin/stdout/stderr are 0/1/2. > c) C FILE*. > > OS handles can be passed around freely within a process; across > processes, they lose their meaning > > It's the data of types b) and c) that cause problems: the CRT handle 4 > means different things depending on what copy of the CRT is interpreting it. Ah, okay. On UNIX systems, of course, a) and b) are identical. > > It's worse with FILE*: passing a FILE* of one CRT to the fread() > implementation of a different CRT will cause a segfault. > >> And, as has already been said in this thread, this does not concern the >> .net developer, or any developer that sticks to managed code, be it >> .net, CPython, or something-else based. > > Since when is CPython managed code? It's not managed code in the "runs on .net" sense, but in principle, it is managed, in that garbage collection is managed for you. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 7 Jul, 00:41, sturlamolden wrote: > It should also be mentioned that the Windows 7 SDK includes > vcbuild.exe, so it can be used to compile Visual Studio 2008 projects > (I'm going to try Python). Not sure why I forgot to mention, but we can (or even should?) use CMake to generate these project files. We don't need Visual Studio for that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 07/06/10 21:19, sturlamolden wrote: On 6 Jul, 21:49, Christian Heimes wrote: I agree, the situation isn't ideal. I see if I can get in contact with Microsoft's open source team. Perhaps they can keep the download link to VS 2008 EE working. It seems the MSDN subscription required to get VS 2008 costs one dollar less than $1200. So it does not fit within everyone's budget. Take in the cost of your operating system, and the ones you want to test against, perhaps you also like to use office. Although I am not a windows developer per se, I do use windows XP, 2000 2003, 2008, Vista and 7 for testing. I also use office for all those clients who think that this is the only format. 1200 USD is actually quite cheap, but then again I didn't pay that because I am either always been in an academic license (about 70 EUR a year) or like now in a program for businesses who just start up (free with my bank as supporting agent). When this 3 year subscription is over I fall anyway in the cheaper renewals and if not I am sure that there is some other brand new scheme like they did for the last decade. Anyway, if you want to provide tools for platforms that are closed source that means that there are costs for the developer and the client. Although the cost for MS platforms are reasonable (as a developer and you know you way around, that means go a couple of times to those free MS events and it is quite likely you get an MSDN subscription for being such a good loyal puppy), there are always costs. If you don't like that better convince your target audience about an open source operating system, whichever that may be. -- mph -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 6 Jul, 21:52, casevh wrote: > The original version of the Windows 7 SDK includes the command line > version of the VS 2008 amd64 compiler. I've used it compile MPIR and > GMPY successfully. The GMPY source includes a text file describing the > build process using the SDK tools. It should also be mentioned that the Windows 7 SDK includes vcbuild.exe, so it can be used to compile Visual Studio 2008 projects (I'm going to try Python). -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
>> - many things which are runtime independent on unix are not on >> windows (file descriptor: AFAIK, a file descriptor as returned from >> open can be dealt with in any C runtime on unix) > > Are you telling me that file descriptors (it's a flippin int!) can't be > passed around universally on Windows?? There are really three things of concern here: a) operating system file handles, of type HANDLE (which is an unsigned 32-bit value); they are not contiguous, and stdin/stdout/stderr may have arbitrary numbers b) C runtime file handles, of type int. They are contiguous, and stdin/stdout/stderr are 0/1/2. c) C FILE*. OS handles can be passed around freely within a process; across processes, they lose their meaning It's the data of types b) and c) that cause problems: the CRT handle 4 means different things depending on what copy of the CRT is interpreting it. It's worse with FILE*: passing a FILE* of one CRT to the fread() implementation of a different CRT will cause a segfault. > And, as has already been said in this thread, this does not concern the > .net developer, or any developer that sticks to managed code, be it > .net, CPython, or something-else based. Since when is CPython managed code? Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 07/07/2010 12:08 AM, David Cournapeau wrote: > On Tue, Jul 6, 2010 at 6:00 PM, Alf P. Steinbach /Usenet > wrote: >> There is no *technical* problem creating a compiler-independent C/C++ >> language binding. > > It is quite hard, though, or would require changes in the API to be > entirely safe. When I asked the question a few months ago to see if we > could fix those issues once and for all for numpy, the most common > answer I got was to pass all the related functions in a structure: > http://stackoverflow.com/questions/1052491/c-runtime-objects-dll-boundaries. > > The problem is not compiler, but really C runtimes. By itself, the > issues are not windows specific (using malloc from one C library and > one free from another one is trouble everywhere), but on windows: > - multiple C runtimes are *very* common on windows I'm also rather sure that it's pretty much impossible to have multiple C libraries in one process on UNIX, but it's obviously quite possible on Windows. > - many things which are runtime independent on unix are not on > windows (file descriptor: AFAIK, a file descriptor as returned from > open can be dealt with in any C runtime on unix) Are you telling me that file descriptors (it's a flippin int!) can't be passed around universally on Windows?? Now Windows programming *really* scares me. > - the MS standard C library is clearly not a priority: win32 specific > objects can be shared across runtimes, but standard C rarely can. And, as has already been said in this thread, this does not concern the .net developer, or any developer that sticks to managed code, be it .net, CPython, or something-else based. > - the recent manifest concept (which can improve or worsen the > issues) is incredibly convoluted, and poorly documented (they expect > you to use MS tool and not to try to understand how it works). Cheers, Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On Tue, Jul 6, 2010 at 6:00 PM, Alf P. Steinbach /Usenet wrote: > * sturlamolden, on 06.07.2010 17:50: >> >> Just a little reminder: >> >> Microsoft has withdrawn VS2008 in favor of VS2010. The express version >> is also unavailable for download.>:(( >> >> We can still get a VC++ 2008 compiler required to build extensions for >> the official Python 2.6 and 2.7 binary installers here (Windows 7 SDK >> for .NET 3.5 SP1): >> >> >> http://www.microsoft.com/downloads/details.aspx?familyid=71DEB800-C591-4F97-A900-BEA146E4FAE1&displaylang=en >> >> Download today, before it goes away! >> >> Microsoft has now published a download for Windows 7 SDK for .NET 4. >> It has the VC++ 2010 compiler. It can be a matter of days before the VC >> ++ 2008 compiler is totally unavailable. >> >> It is possible to build C and Fortran extensions for official Python >> 2.6/2.7 binaries on x86 using mingw. AFAIK, Microsoft's compiler is >> required for C++ or amd64 though. (Intel's compiler requires VS2008, >> which has now perished.) >> >> Remember Python on Windows will still require VS2008 for a long time. >> Just take a look at the recent Python 3 loath threads. > > Perhaps this all for the good. > > There is no *technical* problem creating a compiler-independent C/C++ > language binding. It is quite hard, though, or would require changes in the API to be entirely safe. When I asked the question a few months ago to see if we could fix those issues once and for all for numpy, the most common answer I got was to pass all the related functions in a structure: http://stackoverflow.com/questions/1052491/c-runtime-objects-dll-boundaries. The problem is not compiler, but really C runtimes. By itself, the issues are not windows specific (using malloc from one C library and one free from another one is trouble everywhere), but on windows: - multiple C runtimes are *very* common on windows - many things which are runtime independent on unix are not on windows (file descriptor: AFAIK, a file descriptor as returned from open can be dealt with in any C runtime on unix) - the MS standard C library is clearly not a priority: win32 specific objects can be shared across runtimes, but standard C rarely can. - the recent manifest concept (which can improve or worsen the issues) is incredibly convoluted, and poorly documented (they expect you to use MS tool and not to try to understand how it works). David -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 6 Jul, 21:52, casevh wrote: > On Jul 6, 9:21 am, Thomas Jollans wrote: > > But that doesn't really > > change anything: the express edition of Microsoft's VC++ doesn't include > > an amd64 compiler anyway, AFAIK. See here: http://jenshuebel.wordpress.com/2009/02/12/visual-c-2008-express-edition-and-64-bit-targets/ The express edition can be used as is for x86 though (it might not have an optimizing compiler). It can also be used for C++, unlike g++ (at least VC++ is safer). > The original version of the Windows 7 SDK includes the command line > version of the VS 2008 amd64 compiler. C:\Program Files\Microsoft SDKs\Windows\v7.0>cl Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] C:\Program Files\Microsoft SDKs\Windows\v7.0> Need any more proof? :D Also note that the Windows 7 SDK can still be used with IDEs, like Qt Creator, KDEvelop (yes there is a Windows version), Eclipse, Visual Studio, and even Visual C++ Express (a little PITA for amd64, but possible too). I'm still fan of a tiny text editor for typing (Kate from KDE tends to be my favorite) and a Python script for building, though. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 6 Jul, 21:49, Christian Heimes wrote: > I agree, the situation isn't ideal. I see if I can get in contact with > Microsoft's open source team. Perhaps they can keep the download link to > VS 2008 EE working. It seems the MSDN subscription required to get VS 2008 costs one dollar less than $1200. So it does not fit within everyone's budget. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On Jul 6, 9:21 am, Thomas Jollans wrote: > On 07/06/2010 05:50 PM, sturlamolden wrote: > > > It is possible to build C and Fortran extensions for official Python > > 2.6/2.7 binaries on x86 using mingw. AFAIK, Microsoft's compiler is > > required for C++ or amd64 though. (Intel's compiler requires VS2008, > > which has now perished.) > > mingw gcc should work for building C++ extensions if it also works for C > extensions. There's no difference on the binding side - you simply have > to include everything as extern "C", which I am sure the header does for > you. > > As for amd64 - I do not know if there is a mingw64 release for windows > already. If there isn't, there should be ;-) But that doesn't really > change anything: the express edition of Microsoft's VC++ doesn't include > an amd64 compiler anyway, AFAIK. The original version of the Windows 7 SDK includes the command line version of the VS 2008 amd64 compiler. I've used it compile MPIR and GMPY successfully. The GMPY source includes a text file describing the build process using the SDK tools. casevh > > Also, VS2010 should work as well - doesn't it? > > > > > > > Remember Python on Windows will still require VS2008 for a long time. > > Just take a look at the recent Python 3 loath threads.- Hide quoted text - > > - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
> That's nice to know, but I personally don't have an MSDN subscription. > Many scientists don't have access to development tools like VS2008. > Many hobby developers don't have access expensive MSDN subscriptions. > Many don't develop C personally, but just "needs a compiler" to build > an extension with distutils. And for all of us not subscribing to > MSDN, this is the only remaining source. I agree, the situation isn't ideal. I see if I can get in contact with Microsoft's open source team. Perhaps they can keep the download link to VS 2008 EE working. By the way lot's of universities participate in the MSDN Academy Alliance program. Students, scientists and employees of the university can get most MSDN packages. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On Tue, Jul 6, 2010 at 1:46 PM, Martin P. Hellwig wrote: > Public download that is, people like me who have a MSDN subscription can > still download old versions like Visual Studio 2005. > > So I would say that there is no particular hurry. > I would think that everyone really serious about MS development with MS > tools should get an MSDN subscription anyway, it saves you a lot of money in > the long run. Amazing! -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 6 Jul, 19:46, "Martin P. Hellwig" wrote: > Public download that is, people like me who have a MSDN subscription can > still download old versions like Visual Studio 2005. That's nice to know, but I personally don't have an MSDN subscription. Many scientists don't have access to development tools like VS2008. Many hobby developers don't have access expensive MSDN subscriptions. Many don't develop C personally, but just "needs a compiler" to build an extension with distutils. And for all of us not subscribing to MSDN, this is the only remaining source. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 7/6/10 1:52 PM, Ed Keith wrote: I downloaded the ISO, but it seems to be just a bit too big to fit on a CD! This seems odd to me, has anyone else had this problem? These days, ISOs are destined for DVD-Rs. :-) There are also utilities for mounting ISOs directly without burning them to a physical disk. Here is a decent list: http://www.techsupportalert.com/best-free-cd-emulator.htm -- Robert Kern "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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 6 Jul, 19:52, Ed Keith wrote: > This seems odd to me, has anyone else had this problem? DVD? -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 7/6/10 10:52 AM, Ed Keith wrote: > I downloaded the ISO, but it seems to be just a bit too big to fit on a CD! The website says its a DVD iso. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
I downloaded the ISO, but it seems to be just a bit too big to fit on a CD! This seems odd to me, has anyone else had this problem? -EdK Ed Keith e_...@yahoo.com Blog: edkeith.blogspot.com --- On Tue, 7/6/10, sturlamolden wrote: > From: sturlamolden > Subject: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP > To: python-list@python.org > Date: Tuesday, July 6, 2010, 11:50 AM > > Just a little reminder: > > Microsoft has withdrawn VS2008 in favor of VS2010. The > express version > is also unavailable for download. >:(( > > We can still get a VC++ 2008 compiler required to build > extensions for > the official Python 2.6 and 2.7 binary installers here > (Windows 7 SDK > for .NET 3.5 SP1): > > http://www.microsoft.com/downloads/details.aspx?familyid=71DEB800-C591-4F97-A900-BEA146E4FAE1&displaylang=en > > Download today, before it goes away! > > Microsoft has now published a download for Windows 7 SDK > for .NET 4. > It has the VC++ 2010 compiler. It can be a matter of days > before the VC > ++ 2008 compiler is totally unavailable. > > It is possible to build C and Fortran extensions for > official Python > 2.6/2.7 binaries on x86 using mingw. AFAIK, Microsoft's > compiler is > required for C++ or amd64 though. (Intel's compiler > requires VS2008, > which has now perished.) > > Remember Python on Windows will still require VS2008 for a > long time. > Just take a look at the recent Python 3 loath threads. > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 07/06/10 16:50, sturlamolden wrote: Just a little reminder: Microsoft has withdrawn VS2008 in favor of VS2010. The express version is also unavailable for download.>:(( Public download that is, people like me who have a MSDN subscription can still download old versions like Visual Studio 2005. So I would say that there is no particular hurry. I would think that everyone really serious about MS development with MS tools should get an MSDN subscription anyway, it saves you a lot of money in the long run. -- mph -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
>> You need unofficial version of MinGW with gcc 4.x for several C++ >> extension like PyLucene's JCC. Some project like pywin32 don't work with >> MinGW, too. > > aha - why is that? > > But - if you write code that builds with [whatever gcc version you > have], the compiler Python is built with shouldn't matter, should it? Unless I'm mistaken, official MinGW32 packages still have GCC 3.x. Some projects like JCC need recent C++ compilers. MinGW doesn't provide some features that pywin32 requires. The compiler must create ABI compatible object files and the linker needs to support the latest CRT. Three years ago it took several months until MinGW supported the 9.0 CRT. > Okay, you need to be careful with FILE*s. But malloc and free? You'd > normally only alloc & free something within the same module, using the > same functions (ie not mixing PyMem_Malloc and malloc), would you not? > > You have to code quite defensively, true. But, IF you keep all > non-Python data structures local to your module, you should be fine? You must be carefully with functions like PyFile_FromFile(), too. If you expose the FILE* from the alien CRT to Python somehow you can get into trouble. Lukely PyFile_FromFile() works around most issues but it's still problematic. These kind of SEGFAULTs are hard to debug, too. > Coming from a system where I can generally rely on the system gcc to > work for everything, I may be a bit naïve wrt certain questions ;-) > > PS: Windows CPython programming scares me. Yeah, it's a pain. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 6 Jul, 19:11, Thomas Jollans wrote: > Python is written in C. How does the C++ runtime enter into it? The C and C++ runtimes interact (e.g. stdlib.h and ), malloc and new, etc. With g++ you have a C++ standard library compiled against msvcrt.dll, whereas Python is using msvcr90.dll. We can use the C++ runtime msvcp90.dll used by VC++ 2008, but this DLL is binary incompatible with g++ (GNU uses a different ABI for C++). -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 6 Jul, 19:09, Thomas Jollans wrote: > Okay, you need to be careful with FILE*s. But malloc and free? You'd > normally only alloc & free something within the same module, using the > same functions (ie not mixing PyMem_Malloc and malloc), would you not? You have to be sure PyMem_Malloc is not an preprocessor alias for malloc (I haven't chaecked). In general, CRT objects cannot be shared across CRT boundaries. Also remember the C and C++ standard libraries interact. g++ from links statically with an incompatible C++ standard library (read: it will segfault, it's just a question of when). > Coming from a system where I can generally rely on the system gcc to > work for everything, I may be a bit naïve wrt certain questions ;-) On sane operating systems you generally have one version of libc installed. Windows did this too (msvcrt.dll) up to the VS2003 release, which came with msvcr71.dll in addition. Since then, M$ (pronounced Megadollar Corp.) have published msvcr80.dll, msvcr90.dll, and msvcr100.dll (and corresponding C++ versions) to annoy C and C++ developers into converting to C# .NET. (And yes, programs using third-party DLL and OCX components become unstable from this. You have to check each DLL/ OCX you use, and each DLL used by each DLL, etc. How fun...) -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 07/06/2010 06:49 PM, sturlamolden wrote: > On 6 Jul, 18:21, Thomas Jollans wrote: > >> mingw gcc should work for building C++ extensions if it also works for C >> extensions. > > No, it uses an incompatible statically linked C++ runtime. We need to > use msvcp90.dll with Python 2.6/2.7. Python is written in C. How does the C++ runtime enter into it? > >> As for amd64 - I do not know if there is a mingw64 release for windows >> already. If there isn't, there should be ;-) > > There is. But it does not have an import library for msvcr90.dll. It's > omitted from mingw-w64. Also libpython26.a is missing from Python on > Windows 64. > > >> Also, VS2010 should work as well - doesn't it? > > The problem with Microsoft's compilers is that they just let you pick > between two CRTs (single- or multi-threaded). We need to specify the > version number as well. > > So no, VS2010 will not work. (At least not without some ugly hacks.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 07/06/2010 06:58 PM, Christian Heimes wrote: > Am 06.07.2010 18:21, schrieb Thomas Jollans: >> mingw gcc should work for building C++ extensions if it also works for C >> extensions. There's no difference on the binding side - you simply have >> to include everything as extern "C", which I am sure the header does for >> you. > > You need unofficial version of MinGW with gcc 4.x for several C++ > extension like PyLucene's JCC. Some project like pywin32 don't work with > MinGW, too. aha - why is that? But - if you write code that builds with [whatever gcc version you have], the compiler Python is built with shouldn't matter, should it? > >> Also, VS2010 should work as well - doesn't it? > > It may work, it may segfault. > > The official Python binaries are build with VS 2008. Although you are > able to build and use extensions build with other versions of VS it can > lead to segfaults. So far every version of VS has introduced its own C > runtime library (MSVCRT). If you try to close a FILE* from one MSVCRT > with fclose() from another MSVCRT your program SEGFAULT. malloc() and > free() suffer from the same problem. Okay, you need to be careful with FILE*s. But malloc and free? You'd normally only alloc & free something within the same module, using the same functions (ie not mixing PyMem_Malloc and malloc), would you not? You have to code quite defensively, true. But, IF you keep all non-Python data structures local to your module, you should be fine? Coming from a system where I can generally rely on the system gcc to work for everything, I may be a bit naïve wrt certain questions ;-) Cheers, Thomas PS: Windows CPython programming scares me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
Am 06.07.2010 18:21, schrieb Thomas Jollans: > mingw gcc should work for building C++ extensions if it also works for C > extensions. There's no difference on the binding side - you simply have > to include everything as extern "C", which I am sure the header does for > you. You need unofficial version of MinGW with gcc 4.x for several C++ extension like PyLucene's JCC. Some project like pywin32 don't work with MinGW, too. > Also, VS2010 should work as well - doesn't it? It may work, it may segfault. The official Python binaries are build with VS 2008. Although you are able to build and use extensions build with other versions of VS it can lead to segfaults. So far every version of VS has introduced its own C runtime library (MSVCRT). If you try to close a FILE* from one MSVCRT with fclose() from another MSVCRT your program SEGFAULT. malloc() and free() suffer from the same problem. -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 6 Jul, 18:21, Thomas Jollans wrote: > mingw gcc should work for building C++ extensions if it also works for C > extensions. No, it uses an incompatible statically linked C++ runtime. We need to use msvcp90.dll with Python 2.6/2.7. > As for amd64 - I do not know if there is a mingw64 release for windows > already. If there isn't, there should be ;-) There is. But it does not have an import library for msvcr90.dll. It's omitted from mingw-w64. Also libpython26.a is missing from Python on Windows 64. > Also, VS2010 should work as well - doesn't it? The problem with Microsoft's compilers is that they just let you pick between two CRTs (single- or multi-threaded). We need to specify the version number as well. So no, VS2010 will not work. (At least not without some ugly hacks.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 6 Jul, 18:00, "Alf P. Steinbach /Usenet" wrote: > There is no *technical* problem creating a compiler-independent C/C++ language > binding. I believe that Java's JNI works fine no matter what compiler you use, > although it's many many years since I've done JNI things. Similarly, Python > should IMHO just have a well defined compiler independent native code > interface, > e.g. "PNI", or "pynacoin", the PYthon NAtive COde INterface :-) Yes but Python currently does not, due to dependency on VS2003 (2.5) or VS2008 (2.6, 2.7, 3.1) C and C++ runtime DLLs. It's not the binary interface that is the trouble, but CRT versioning. C++ is extra troublesome due to name mangling, standard runtime and exceptions. Here are the issues: C++: VS2010 - does not link with msvcp90.dll but msvcp100.dll. mingw - linkes statically with its own C++ library. Win32, ANSI C: VS2010 - does not link with msvcr90.dll but msvcr100.dll. mingw - ok for C if passed -lmsvcr90 on linking step Win64, ANSI C: VS2010 - does not link with msvcr90.dll but msvcr100.dll. mingw - missing import libraries (libmsvcr90.a and libpython26.a) Visual Studio 2008's C/C++ compiler is the only sane solution. It is still there so go get it if you don't already have a copy (I guess Alf does). -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On 07/06/2010 05:50 PM, sturlamolden wrote: > It is possible to build C and Fortran extensions for official Python > 2.6/2.7 binaries on x86 using mingw. AFAIK, Microsoft's compiler is > required for C++ or amd64 though. (Intel's compiler requires VS2008, > which has now perished.) mingw gcc should work for building C++ extensions if it also works for C extensions. There's no difference on the binding side - you simply have to include everything as extern "C", which I am sure the header does for you. As for amd64 - I do not know if there is a mingw64 release for windows already. If there isn't, there should be ;-) But that doesn't really change anything: the express edition of Microsoft's VC++ doesn't include an amd64 compiler anyway, AFAIK. Also, VS2010 should work as well - doesn't it? > > Remember Python on Windows will still require VS2008 for a long time. > Just take a look at the recent Python 3 loath threads. > -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
* sturlamolden, on 06.07.2010 17:50: Just a little reminder: Microsoft has withdrawn VS2008 in favor of VS2010. The express version is also unavailable for download.>:(( We can still get a VC++ 2008 compiler required to build extensions for the official Python 2.6 and 2.7 binary installers here (Windows 7 SDK for .NET 3.5 SP1): http://www.microsoft.com/downloads/details.aspx?familyid=71DEB800-C591-4F97-A900-BEA146E4FAE1&displaylang=en Download today, before it goes away! Microsoft has now published a download for Windows 7 SDK for .NET 4. It has the VC++ 2010 compiler. It can be a matter of days before the VC ++ 2008 compiler is totally unavailable. It is possible to build C and Fortran extensions for official Python 2.6/2.7 binaries on x86 using mingw. AFAIK, Microsoft's compiler is required for C++ or amd64 though. (Intel's compiler requires VS2008, which has now perished.) Remember Python on Windows will still require VS2008 for a long time. Just take a look at the recent Python 3 loath threads. Perhaps this all for the good. There is no *technical* problem creating a compiler-independent C/C++ language binding. I believe that Java's JNI works fine no matter what compiler you use, although it's many many years since I've done JNI things. Similarly, Python should IMHO just have a well defined compiler independent native code interface, e.g. "PNI", or "pynacoin", the PYthon NAtive COde INterface :-) Cheers, - Alf -- blog at http://alfps.wordpress.com> -- http://mail.python.org/mailman/listinfo/python-list