Martin, thanks for the tip, I wasn't fully aware of that. OTOH, though GCC might be a theoretical alternative, it isn't a practical one for many situations:
* In a professional environment, it opens up another can of potential problems, where one would rather like to stay with one single compiler/build system. * I suppose Python's distutils have to be tweaked to work with GCC * The Makefiles/build system will need to be changed to work with the GCC toolchain * The different semantics of GCC and Microsoft C often need rewriting some of the code * There is no support for MFC/ATL in GCC * The code created by the Windows GCC is not as good as the one created by the Microsoft compiler Markus Martin v. Löwis wrote: > [EMAIL PROTECTED] wrote: > > the problem is not the ABI, but the runtime libraries. From what you're > > saying, it looks like we will have to standardize on VS2003. As I said, > > we need to buy VS anyway because of the MFC support. On the other hand, > > I really worry about all those people that want to build open source > > extensions for Python 2.5. It is really possible that there will be no > > legal, free way to do that soon if you don't have an old installation > > of the 2003 toolkit lying around somewhere... > > As others have pointed out already: This is not true. You can build > Python extensions with GCC just fine; gcc provides an import library > for msvcr71.dll. > > It might be possible to integrate an msvcr71.dll import library > with VS 2005, in which case you could use VS 2005 to create Python > extensions as well. > > Regards, > Martin -- http://mail.python.org/mailman/listinfo/python-list
