[Python-Dev] MS VC 7 offer (original) (raw)

Harri Pasanen harri.pasanen@trema.com
Wed, 7 May 2003 10:31:08 +0200

On Tuesday 06 May 2003 22:26, Martin v. L=F6wis wrote:

Alex Martelli wrote: > When we discussed VC versions (back when we met in Ofxord during > PythonUK/ACCU), David Abrahams seemed adamant that VC7 and VC6 > are indeed compatible

I doubt he said this in this generality: he surely knows that you cannot mix C++ objects files on the object file level between those compilers, as they implement completely different ABIs. For Python, the biggest problem is that you cannot pass FILE* from one C library to the other, because of some stupid locking test in the C library. This does cause crashes when you try to use Python extension modules compiled with the wrong compiler.

One known failure case from the real world is the OmniORB free CORBA=20 ORB. The omniidl parser, which is implemented as a mixture of python=20 and C++ requires that python is compiled with the same VC version as=20 you are compiling OmniORB with.

So if you are using VC7 to compile OmniORB, you cannot use the binary=20 Python 2.2.2 from pythonlabs for it, you need to compile your own=20 python using VC7. I believe it is the FILE * that is causing the=20 problem here. If I recall correctly, the size of the underlying FILE=20 struct is different in msvcrt.dll and msvcrt7.dll. I don't know the=20 gory details, I just know the cure. This issue was also in omniORB=20 mailing list.

=46or our own product we have to support both VC6 and VC7. For our=20 development version we have actually imported python 2.3 to our CVS,=20 and we are compiling it with VC7.1. Our previous release continues=20 to rely on VC6, and Python 2.2.2, so each develeloper actually has=20 both VC6 and VC7.1 installed on their machine, and correspondingly=20 both python 2.2.2 and python 2.3.

Just another datapoint.

=2DHarri