Steve Dower added the comment: > 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?
AFAICT, all of the "public" functions exported from vcruntime140.dll are also exported from api-ms-win-crt-string-l1-1-0.dll (which forwards to ucrtbase.dll), which would make them available as part of the stable ABI. I'm not sure why vcruntime140.dll has its own versions or why they are used in preference, but it may be to do with inlining or intrinsics. vcruntime140.dll exists and is not guaranteed stable because it provides functionality that needs intimate knowledge of the compiler (stack unwinding, etc.). Those string APIs don't make much sense here, so I'd guess they're dependencies that had to be pulled in, and the linker may just be prioritizing those ones by accident. I would not be at all surprised if MinGW had to replace vcruntime140.dll entirely. Nothing from ucrtbase.dll can depend on it, so replacing it is probably for the best. Then just link against either the ucrtbase.dll or the api-ms-win-crt-*.dll libraries. ---------- _______________________________________ 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
