-1

Extensions are just dynamic link library, which should not have problem across different version of MSVC.

xuhdev
  • 8,018
  • 2
  • 41
  • 69
  • Even on the same OS, a dll that is compiled on two different compilers is not identical. That is (among other reasons) [why it is so dangerous to pass standard library containers across dlls](https://stackoverflow.com/questions/22797418/how-do-i-safely-pass-objects-especially-stl-objects-to-and-from-a-dll). – Cory Kramer Mar 03 '15 at 19:57
  • @Cyber I know it's not identical, but for C extensions this should be ABI compatible. – xuhdev Mar 03 '15 at 19:59

2 Answers2

2

Many extensions need to access or create CPython objects with the same byte-for-byte layout and they must be allocated by the main program, they must be manageable by the garbage collector and so on.

Python can call any DLL without problems (es. using ctypes) but extensions are more than just a DLL and more than calling convetion compatibility is needed.

6502
  • 112,025
  • 15
  • 165
  • 265
2

Different versions of the Microsoft compilers link to version specific C runtime libraries. IIRC, there are differences in IO and memory allocation. If the extension doesn't rely on the C runtime behavior that varies between versions, then the extension module will work. But an extension module that can reference any arbitrary C code could invoke an incompatibility in the different runtime libraries. It is much easier to say "You must use the same version." than "If you only use this subset of C, then you can use any version; otherwise, you must use the same version."

casevh
  • 11,093
  • 1
  • 24
  • 35
  • The main trouble spots that I know of are pairing calls to `malloc` and `free`, operating on `FILE` streams, and the mapping between Windows handles and file descriptors. These are all managed individually for each C runtime in a process. Has anyone had a problem using, e.g. msvcrt.dll via MinGW, regarding stack corruption or alignment problems? – Eryk Sun Mar 04 '15 at 02:46