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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4