[Python-Dev] Linking with mscvrt

["Martin v. Löwis"]

Giovanni Bajo wrote:
>>I just came up with an idea how to resolve the VC versioning
>>problems for good: Python should link with mscvrt.dll (which
>>is part of the operating system), not with the CRT that the
>>compiler provides.
> 
> 
> Can you elaborate exactly on which versioning problems you think of?

I could, but I don't want to elaborate too much. Please google for
it - there has been written a lot about it.

In short, you cannot really link two different versions of msvcrt
(e.g. mscvrt.dll, msvcrt4.dll, msvcr7.dll, msvcr71.dll, mscvrtd.dll,
msvcr71d.dll, ...) into a single program, plus you cannot redistribute
the CRT unless you are a Visual Studio licensee. This causes problems
for extension writers: they need to own the same version of visual
studio that Python was built with.

> It would complicate the build process and make Python lag behind CRT
> development (including bugfixes and whatnot) that Microsoft does.

There isn't really too much development in the CRT, and the little
development I can see (e.g. in VS 2005) is rather counter-productive.
So ideally, Python should drop usage of the CRT entirely (but getting
there will be a long process). Hopefully, P3k will drop usage of
stdio for file objects, which will be a big step forward.

> You could
> as well ask to always stick with GCC 2.95 to solve ABI problems, but I don't
> think it's the correct long time solution. I expect more and more Windows
> libraries (binary version) to be shipped with dependencies on MSVCR71.DLL.

Now that VS2005 is out, I doubt that. More and more will also depend on
msvcr80.dll. Then, when the next visual studio comes out, you can
(probably) add msvcr81.dll to the list of libraries that might be used.
This will go on forever, and we cannot win.

It's really not using GCC 2.95 which I'm after. It's using /lib/libc.so
that I want to. People should be free to use whatever compiler they have
access to.

Regards,
Martin