[Python-Dev] MS VC 7 offer

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.