Michael Foord wrote: > On 30/08/2010 17:35, Barry Warsaw wrote: >> On Aug 30, 2010, at 10:18 PM, Nick Coghlan wrote: >> >>> Since the Linkage section of PEP 384 specifically states the >>> availability of a generic "python3.dll" that dynamically redirects to >>> the relevant "python3y.dll" to allow an extension module to run >>> against any 3.2 or later Python version as a goal of the PEP, I would >>> say that allowing mixing of C runtimes is definitely one of the PEP's >>> goals. >> It should be explicit about that then, and provide detail about why the >> runtime is relevant to Windows programmers (and probably not relevant in >> practice for *nix programmers). > > An extension compiled for one version of Python will be linked against > the version of the C runtime used by that version of Python (if it is > compiled with the same version of Visual Studio of course). > > If the extension binary is to remain compatible with a later version of > Python, compiled against a different version of the C runtime, then it > *must* be possible for multiple C runtimes to be loaded.
Is it possible to have multiple versions of the lib C loaded on Windows ? I know that it is not possible on Linux. Instead, the glibc takes great care to version all sorts of APIs in the lib to make it possible to run applications using different versions within the same runtime (they include different ABI versions in the same lib). AFAIK, on Windows, the lib C is using a different approach: up until the invention of the manifests, they took great care not to break the APIs in incompatible ways. With manifests, things are more complicated, since the DLLs now explicitly reference a particular version of a DLL (down to the patch level) and if the versions are not installed, the application won't run. Not sure what effect that has on the way they engineered the new lib C versions... This document suggests that it is possible to have an application use multiple CRTs, but care has to be taken with respect to things that are initialized by the CRTs (env vars, locales, handles, etc.): http://msdn.microsoft.com/en-us/library/abx4dbyh(v=VS.90).aspx > If the stable > ABI doesn't allow this then binaries will *still* have to be recompiled > when we update the version of Visual Studio used to compile Python - > defeating the purpose of the PEP. Right? If we keep changing the main compiler version used for creating Python binaries on Windows: yes. Fortunately, we don't :-) On Unix this shouldn't be too much of a problem, though, so the PEP is still valid for those platforms. > If this is the case then I agree that it should be explicit in the PEP. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 27 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2010-08-19: Released mxODBC 3.1.0 http://python.egenix.com/ 2010-09-15: DZUG Tagung, Dresden, Germany 18 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
