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

David Abrahams dave@boost-consulting.com
Tue, 06 May 2003 19:05:41 -0400

"Martin v. L=F6wis" <martin@v.loewis.de> writes:

David Abrahams wrote:

Actually, I did. I may have overstated the case slightly, but not by much. Hmm. While this is certainly off-topic for python-dev, I'm still curious. So I just did this: 1. Create a library project with VC6. Put a single class into a single translation unit #include <afx.h> struct X:public CObject{ X(); }; 2. Compile this library with vc6. 3. Create an MFC application with VC7. Instantiate X somewhere. Try to link. This gives the error message LINK : fatal error LNK1104: cannot open file 'mfc42d.lib' Sure enough, VC7 does not come with that library. So it seems very clear to me that the libraries shipped are incompatible in a way that does not allow to mix object files of different compilers. Did I do something wrong here?

I normally don't think of the contents (or naming) of a non-standard library like MFC that just happens to ship with the compiler as being something that affects object-code compatibility. If you accept the way I see that term, your test doesn't say anything about it. Certainly for any accepted definition of "ABI", it's hard to connect your test with the claim that "they implement completely different ABIs".

You could make a reasonable argument that differences in the standard 'C' or C++ library affects object code compatibility; frankly I have avoided that area so I don't know whether there are problems with the 'C' library but I know the C++ library underwent a major overhaul, so I wouldn't place any bets.

Regardless, when I say "object code compatibility", I'm talking about what's traditionally thought of as the ABI: the layout of objects, calling convention, mechanics of the runtime, etc., all of which are basically library-independent issues.

HTH2, --=20 Dave Abrahams Boost Consulting www.boost-consulting.com