From: Thomas Jollans on
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
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
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
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
>> 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.