[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.
=2DHarri