I guess those imports are expected to come from vcruntime. Rebuilding the static libraries may be the only option then, sorry (on the bright side, VC 14 has much better C99 support than earlier versions, so things should be better once we get past the problems caused by change).

Marc-Andre: there are a few concerns with including DLLs that aren't new with any of the 3.5 changes.

* depending on another CRT version is fine *if* it is available (users may have to be told/helped to install the redistributable themselves)
* CRT state will not be shared between versions. This is most obviously a problem if file descriptors are shared, but may also appear when writing console output, doing floating-point calculations, threading, and memory management.
* potentially many more issues if C++ is used, but since Python doesn't use C++ this is mainly a concern where you have two DLLs using C++ and different runtimes (the CRT is partially/fully implemented in C++, so issues may theoretically occur with only one DLL using C++, but I'm yet to see any in practice or even identify any specific issues - maybe it's fine? I'm not going to guarantee it myself)

The parts of the new CRT that will be statically linked are (broadly):
* process/DLL initialization
* exception handling
* some functions that are also compiler intrinsics

The first two don't apply for C static libraries, and even seem to be okay if the static lib is the one declaring main(). I did make the argument that they should be statically linked by default, but the response was that security patches may need to be applied to those parts of the code (particularly exception handling - corrupting the stack and then raising an exception is a great way to jump to whatever code you like). If Python shipped this DLL, it would not be updateable anyway, so static linking is a considered risk that could cause us to someday ship a security update due to a change in the CRT (exactly as has been the case for every other version of Python - nothing new here).

The last item is what Christoph just hit - because the compiler may partially inline those functions (memchr, strchr, etc.) for fast paths, it needs intimate knowledge about how they are implemented. As a result, they go in the compiler-version specific DLL and not the generic one. This lets the implementations make assumptions about what conditions the compiler has already tested and/or proven, but since this could change with compiler version the implementation may also change.

Since the functions are stateless, there's no issue if they happen to be included in a final DLL multiple times for different versions, but that will only happen if the original library is compiled with /MT (I checked - there's no way to override the code generated here under /MD other than to change the compiler option, but link-time code generation should be able to take /MT-compiled libraries and dynamically link them).

So basically, there are no new restrictions on linking to dynamic libraries. The biggest concern would be if those libraries depend on msvcr100.dll and worked with Python 3.4 (which shipped msvcr100), they may not work on Python 3.5 unless the user has obtained msvcr100.dll some other way.