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: Thomas Jollans on 6 Jul 2010 13:09 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.
From: Thomas Jollans on 6 Jul 2010 13:11 On 07/06/2010 06:49 PM, sturlamolden wrote: > On 6 Jul, 18:21, Thomas Jollans <tho...(a)jollans.com> 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.)
From: sturlamolden on 6 Jul 2010 13:35 On 6 Jul, 19:09, Thomas Jollans <tho...(a)jollans.com> 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...)
From: sturlamolden on 6 Jul 2010 13:43 On 6 Jul, 19:11, Thomas Jollans <tho...(a)jollans.com> 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 <iostream>), 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++).
From: Christian Heimes on 6 Jul 2010 13:49
>> 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. |