On 15.08.2015 22:41, Steve Dower wrote: > > 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)
These issues have always existed in the past, but were never a real problem, AFAIK, since the libraries intended to be used externally will typically come with e.g. memory management APIs to make sure they retain ownership of the allocated memory on their heap. It is quite natural to have to run VCredist as part of an application installer to make sure that the target system has the right VC runtime DLLs installed (and the installer will do the checking). The purpose of having DLLs for the runtime is to reduce overall size of the components as well as being able to easily address bugs and security issues in the runtime DLLs *without* having to recompile and redeploy all components using them. By forcing or even suggesting statically compiled Python C extensions, we would break this goal and potentially put our users at risk. IMO, we should follow the MS recommendations for "Deployment in Visual C++" as we did in the past: https://msdn.microsoft.com/en-us/library/dd293574.aspx """ You can statically link a Visual C++ library to an application—that is, compile it into the application—so that you don't have to deploy the Visual C++ library files separately. However, we caution against this approach because statically linked libraries cannot be updated in place. If you use static linking and you want to update a linked library, you have to recompile and redeploy your application. """ Perhaps I'm missing something, but if the only advantage of statically compiling in the runtime is to have users not need to run VCredist at install time, it's not worth all the added trouble this introduces. If you are trying to make it possible to compile extensions with compilers following VC2015, then I also don't think this approach will work: the new compilers will use a new runtime and so issues you describe above come into play between the extensions and the interpreter. In that scenario, they will create real problems, as far as I understand, the since the Python C API expects to be able to e.g. share FDs, internal state such as which locale to assume, or use and free memory allocated by either the interpreter or the extension in the resp. other component (e.g. PyArg_ParseTuple()). So in the end, you'll still have to use the same compiler for extensions as the one used for compiling CPython to make sure you don't run into these issues - which is essentially the same situation as for Python <=3.4. -- Marc-Andre Lemburg eGenix.com _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com