Unfortunately applocal deployment doesn't solve the versioning issue - you'll always need to use VS 2015 to build for Python 3.5.

There are only a few more libraries that are affected by /MT. msvcp140.dll is the most likely one here. Doing the same /nodefaultlib dance for that might work, but it may not.

All of the shared state like memory allocation and file descriptors are in ucrt, which will not change with compiler versions. CPython itself does not require any extensions to use VS 2015 as long as they link to ucrtbase and not another CRT, but it's looking like the same build process won't work everywhere else.

Installing the full runtime requires administrative privileges, and removing that requirement was one of the priorities. If certain extensions require it or if distros install it that's fine, but I don't want distutils to *help* people make wheels that won't work on another machine because the runtime isn't there.

Depending on the size difference, statically linking the C++ parts may not be so bad. It's certainly no worse than including it local to Python, and all of its potentially shared state should be handled by the ucrt already.

Also, I've already had that OpenSSL issue fixed upstream. You must have an older version - I've been building it fine without patching for months now.