[Python-Dev] MS VC 7 offer

[David Abrahams]

"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