Carl Kleffner added the comment: > Windows itself is the primary user of msvcrt.dll. > A Windows 7 installation has over 1500 DLLs and over > 350 executables in System32 that depend on msvcrt.dll. > Windows developers such as Raymond Chen get a bit annoyed > when projects link directly with msvcrt.dll.
In case of mingw32 or mingw-w64 msvcrt linkage is the usual standard due to licensing reasons. The CRT has to be stated as a 'System' library, see http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL. This is case for msvcrt.dll only. VC runtimes can be linked as well, but this runtime DLLs should'nt deployed alongsinde with the application in this case. As described above python binary extensions has to be linked against the very same VC runtime that is used for Python itself to avoid mixing runtimes in one application. Mixing is considered as evil, see http://siomsystems.com/mixing-visual-studio-versions An important question for Steve concerning python-3.5: python-3.5b2 is linked against the newly introduced 'universal CRT', that is without any doubt a SYSTEM LIBRARY. However, heap memory managment functions and other functions are linked against VCRUNTIME140.dll instead of the ucrtbase.dll. Is this the intended behavior? The symbol memset: this symbol is exposed from ucrtbase.dll as well as vcruntime140.dll. Is it necessary to link python binaries against vcruntime140.dll as well, or is linkage against ucrtbase.dll sufficient? ---------- nosy: +carlkl _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24429> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
