[issue4709] Mingw-w64 and python on windows x64
Carl Kleffner added the comment: The situation is not THAT bad. You can install a prerelease of mingwpy with pip: pip install -i https://pypi.anaconda.org/carlkl/simple mingwpy or with conda: (thanks to omnia-md) conda install -c https://conda.anaconda.org/omnia mingwpy It is not hosted on PYPI as long as there is no version for python-3.5. -- nosy: +carlkl ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24429] msvcrt error when embedded
Carl Kleffner added the comment: Windows itself is the primary user of msvcrt.dll. A Windows 7 installation has over 1500 DLLs and over 350 executables in System32 that depend on msvcrt.dll. Windows developers such as Raymond Chen get a bit annoyed when projects link directly with msvcrt.dll. In case of mingw32 or mingw-w64 msvcrt linkage is the usual standard due to licensing reasons. The CRT has to be stated as a 'System' library, see http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL. This is case for msvcrt.dll only. VC runtimes can be linked as well, but this runtime DLLs should'nt deployed alongsinde with the application in this case. As described above python binary extensions has to be linked against the very same VC runtime that is used for Python itself to avoid mixing runtimes in one application. Mixing is considered as evil, see http://siomsystems.com/mixing-visual-studio-versions An important question for Steve concerning python-3.5: 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? The symbol memset: this symbol is exposed from ucrtbase.dll as well as vcruntime140.dll. Is it necessary to link python binaries against vcruntime140.dll as well, or is linkage against ucrtbase.dll sufficient? -- nosy: +carlkl ___ 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
[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects
Carl Kleffner added the comment: I experienced this behaviour by accident several times. Most likely this is due to inconsistenticies in different binutils and mingw-runtime versions/patches. See i.e. http://article.gmane.org/gmane.comp.gnu.binutils/46799 A robust solution is to exclusively use import libraries created by the toolchain used for building python extensions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24385 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects
Carl Kleffner added the comment: The most robust way to support a specific mingw-w64 distribution is to copy a python import library generated by this specific toolchain and the provided import library for the corresponding msvcrXX.dll runtime into the libs folder. This has to be performed by the user with the help of gendef and dlltool. Another atempt is to install and use a specific mingw-toolchain that copies these files into the libs folder during install. Such a toolchain will be provided in the near future as 'mingwpy' toolchain for python2.7-3.4. -- nosy: +carlkl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24385 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
