Building Python 2.7.10 with Visual Studio 2010 or 2015 - Google Chrome

您的浏览器(Chrome 33) 需要更新。该浏览器有诸多安全漏洞，无法显示本网站的所有功能。 了解如何更新浏览器
×

Building Python 2.7.10 with Visual Studio 2010 or 2015

7th revision, August 7, 2015.
A document history can be found at the very end of this page

Downloads

For the impatient:

NameVisual Studio 2010Visual Studio 2015
Python 2.7.10 32-bitDownloadDownload
Python 2.7.10 32-bit SourcesDownloadDownload
Python 2.7.10 64-bitDownloadDownload
Python 2.7.10 64-bit SourcesDownloadDownload

Note: these builds use updated versions of OpenSSL (1.0.2d) and SQLite (3.8.11), plus tons of other new goodies.

Why bother?

Python on Windows is built with Visual Studio 2008 Professional. If you have an application built with Visual Studio 2010 (or any other Visual Studio version), and you have Python embedded in it, you have two problems:

  1. It is a very bad idea to mix different Visual C++ runtimes. See http://siomsystems.com/mixing-visual-studio-versions/ for an explanation. This means if you use the official libraries to link in Python, you are in for some nasty surprises.
  2. The official distribution does not contain debug libraries. For some reason I don’t fully understand the python libraries have different names for debug and release builds (rather than just be located in a different directory, as I would normally approach this). This means that you cannot easily build a working debug build of your project.

So, you need to rebuild Python with the Visual Studio version you are using. In the following post I am going to explain what you need to do.

Build Instructions

Get the sources from http://python.org/download/. At the time of this writing, Python 2.7.10 is the official release, so I will usePython-2.7.10.tgz in the following.

Extract the files. You’ll get a folder Python-2.7.10 with several subfolders for sources, headers and so on.

Go to the PCBuild folder and open readme.txt in an editor capable of showing unix-style newlines, i.e. ANYTHING BUT NOTEPAD. I personally am a hardcore fan of scite, which is available at http://www.scintilla.org/SciTE.html.

Read readme.txt. No, I mean seriously: read it. In particular, let’s recap the section named Python-controlled subprojects that wrap external projects and follow slowly.

We’ll start at the top, with SQLite:

_sqlite3
Wraps SQLite 3.6.21 which is currently built by sqlite3.vcproj (see below).

Well, 3.6.21 is old – it dates back from 2009. So since we’re going to rebuild everything anyway, why not upgrade sqlite as we go along? (You might not care so much, but me being a heavy SQLite user do). If you open the project sqlite3.vcproj in an editor (SciTE), you’ll see that the sources are supposed to be in a directory with the variable $(sqlite3Dir), which in turn is kept inpyproject.vsprops. Once you open that in an editor, you’ll notice it defines all the dependent directories as well. Take a look at this:

    ...
	<UserMacro
		Name="sqlite3Dir"
		Value="$(externalsDir)\sqlite-3.6.21"
	/>
	<UserMacro
		Name="bz2Dir"
		Value="$(externalsDir)\bzip2-1.0.6"
	/>
	<UserMacro
		Name="opensslDir"
		Value="$(externalsDir)\openssl-0.9.8y"
	/>
    ...

So first we’re going to update sqlite. No risk, no fun! Head over to sqlite.org and download the latest amalgamation sources; at the time of the writing these were 3.8.10. Extract the archive, you should have 4 files in there. Now, where to move the files: notice that..\.. is the externals directory, which is on the same include level as Python-2.7.10. Add a folder sqlite-3.8.10 and copy the amalgamation files there.

Next, you’ll also need bzip2-1.0.6. Download the source tarball at http://www.bzip.org/downloads.html and install it in the correct directory.

Next, you’ll also need db-4.7.25.0. Do a svn export http://svn.python.org/projects/external/db-4.7.25.0 so that the folder is right next to the Python-2.7.10 one.

Next, openssl. There is a version 1.0.1e in subversion, but 1.0.1m is current, and we want to have a current SSL, don't we? At this point, I should probably point out that I have written together specific instructions on building version 1.0.1g.

The TCL/TK problem child

Building TCL/TK support for Python is insert curse-word here, and in the first version of this document I refused to build it. But I've since managed to build it, and I include the instructions here even though I still believe it to be pretty pointless. But anyway, I digress.

  • Go to your Python source directory.
  • Run Tools\buildbot\external.bat

Ok, this will fail, for two reasons:

  1. tcl-8.5.2.1\generic\tclPosixStr.c uses some POSIX cases more than once (at least under the defines available on Windows). I've modified the source, it is part of the download. For reference, the problem looksl ike this:
    tclPosixStr.c
..\generic\tclPosixStr.c(347) : error C2196: case value '123' already used
..\generic\tclPosixStr.c(407) : error C2196: case value '121' already used
..\generic\tclPosixStr.c(795) : error C2196: case value '123' already used
..\generic\tclPosixStr.c(855) : error C2196: case value '121' already used
  2. The makefiles use the obsolete syntax -debug:Full for the linker; this must be replaced by -debug. To find out which files are affected, do this:
    C:\Python27\Source>grep -r "debug:full" *
Python-2.7.10/output.txt:        link -nologo -machine:IX86 -ltcg -debug:full -debugtype:cv -dll -base:@..\win\coffbase.txt,tcl -out:.\Debug_VC9\tcl85g.dll  kern
el32.lib user32.lib ws2_32.lib @C:\Users\Gerson\AppData\Local\Temp\nmFA32.tmp
Python-2.7.10/output.txt:LINK : fatal error LNK1117: syntax error in option 'debug:full'
Python-2.7.10/output.txt:        link -nologo -machine:IX86 -ltcg -debug:full -debugtype:cv -dll -base:@"..\..\tcl-8.5.2.1\win\coffbase.txt",tk -out:".\Debug_VC9
\tk85g.dll" kernel32.lib user32.lib gdi32.lib  "..\..\tcl-8.5.2.1\win\Debug_VC9\tclstub85.lib" @C:\Users\Gerson\AppData\Local\Temp\nm5B23.tmp
Python-2.7.10/output.txt:LINK : fatal error LNK1117: syntax error in option 'debug:full'
tcl-8.5.2.1/win/configure:      LDFLAGS_DEBUG="-debug:full"
tcl-8.5.2.1/win/makefile.vc:ldebug      = -debug:full -debugtype:cv
tcl-8.5.2.1/win/makefile.vc:@LDFLAGS_DEBUG@      -nologo -machine:$(MACHINE) -debug:full -debugtype:cv
tcl-8.5.2.1/win/tcl.m4: LDFLAGS_DEBUG="-debug:full"
tk-8.5.2.0/win/configure:       LDFLAGS_DEBUG="-debug:full"
tk-8.5.2.0/win/makefile.vc:ldebug       = -debug:full -debugtype:cv
tk-8.5.2.0/win/tcl.m4:  LDFLAGS_DEBUG="-debug:full"

Once you've done this, the external.bat runs through ... and creates debug binaries. Great, just what we needed, right

No. You probably want to make a release build as well, and for that you need to patch external.bat once more:

  1. Run notepad Tools\buildbot\external.bat and replace DEBUG=1 with an empty string.
  2. Still in notepad, replace tcl85g.dll with tcl85.dll, and tk85g.dll with tk85.dll
  3. Close the file, continuing to hate TCL/TK.

Doing the actual build (for 32-bit Windows)

OK, time to open Pcbuild.sln. I am doing this with Visual Studio 2010, the IDE asks me whether I want to upgrade the projects: yes, I do

Open the batch build options dialog and select all 32-bit debug and release binaries. Batch build ahead!

You’ll see a ton of warnings like this:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): warning MSB8012: TargetPath(C:\Python27\Source\Python-2.7.10\PCbuild\\pythoncore.dll) does not match the Linker's OutputFile property value (C:\Python27\Source\Python-2.7.10\PCbuild\python27.dll). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(992,5): warning MSB8012: TargetName(pythoncore) does not match the Linker's OutputFile property value (python27). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).

Apparently, this is a well-known issue and you basically have to either ignore this warning, or edit all projects (mostly in the debug build of the project) as per the stackoverflow.com recommendation; like this:

  • In the project settings, for the Debug build, if you have a Linker/Output File like this: $(OutDir)$(ProjectName)_d.pyd (example: unicodedata), you need to change
    • General/Target Name from $(ProjectName)_d to $(ProjectName)_d.
    • General/Target Extension from .dll to .pyd.
  • In the project settings, for the Release build, if you have a Linker/Output File like this: $(OutDir)$(ProjectName).pyd (example: unicodedata), you need to change
    • General/Target Extension from .dll to .pyd.

You get the idea...

Note: Starting with Revision 4 of this document, the source download includes project files that have been patched to correct this issue. In other words, if you download the source on this page and rebuild for yourself, you will not get these warnings any longer.

After the build completes, for me I get a single project not done: bsddb. This is actually a problem in the project conversion, because you see ton's of erros like this:

19>c1 : fatal error C1083: Cannot open source file: 'repmgr\repmgr_windows.c': No such file or directory
19>  rijndael-alg-fst.c

which means the project expects db-4.7.25.0 to be a subdirectory of PCBuild rather than in the location where it is actually is. Do this:

  • Close Visual Studio (or unload the project).
  • Open _bsddb.vcxproj in an editor and change references from
    <ClCompile Include="btree\bt_upgrade.c" />
    to
    <ClCompile Include="..\..\db-4.7.25.0\btree\bt_upgrade.c" />
  • Open _bsddb.vcxproj.filters in an editor and do basically the same

You'll also have problems building tkinter.pyd. After all the shit you've had to go through above, this seems a bit unfair, but well: that is life.

Error	110	error LNK1181: cannot open input file '..\..\tcltk\lib\tcl85.lib ..\..\tcltk\lib\tk85.lib'	C:\Python27\Source\Python-2.7.10\PCbuild\LINK	_tkinter

AAAAAAAAAAAAAAAAAAA. Did I mention that TCL/TK is shit? Add hardcoded lines to the lib files you just built, and it'll find the files.

Understanding the mysteries surrounding the Python Debug builds

Why Batch Building both Debug and Release targets fails

The Visual Studio solution contains both Debug and Release targets. These have separate names following the standard conventions: so for example there is a _ctypes.pyd in Release Build, and a _ctypes_d.pyd in Debug Build.

This holds true for allmost all projects in the solution: except for four:

  1. make_buildinfo.exe. This is the one that is causing the problem, and the problem is that this project is built first to create a configuration file used in subsequent builds. And if you do batch-build, then this file is created only once, so its settings are overwritting the settings for the other projects. Solution: do a separate debug and release build, and you'll be fine
  2. w9xpopen.exe. Let me quote the documentation: " Serves as an intermediate stub Win32 console application to avoid a hanging pipe when redirecting 16-bit console based programs (including MS-DOS console based programs and batch files) on Window 95 and Windows 98.". OK, this is for Windows 95, a version that will be 20 years old soon. If you are still use the Win9x series, you don't deserve an upgraded Python build :) so I choose not to include it in the binary distribution.
  3. kill_python.exe. This is a helper program, quote, " for killing lingering python[_d].exe processes before building, thus attempting to avoid build failures due to files being locked.". OK, this is basically the same in both debug and release builds.
  4. make_versioninfo.exe. This file generates the resource file version number, and OK this is the same in debug and release builds, so no problems here.

Building an updated install

  • First, you install the standard windows distribution for 2.7.
  • This installer puts python27.dll in windows\system32 (or in windows\syswow64 if you’re running on 64-bit windows). You need to remove it there, because you want to create a distribution that is fully movable.
  • Update the binaries in C:\python27 and C:\python27\dlls. Note that for every .exe, .dll and .pyd, there should be two forms inPCBuild: a blabla.dll and a blabla_d.dll and so on. Copy both.

Doing the actual build for 64-bit Windows

  • Most of the above comments apply to the 64-bit build as well.
  • Note that make_buildinfo and make_versioninfo are not 64-build compatible. You build the 32-bit version, and then you reuse the 32-bit version in the 64-bit batch build...
  • Binaries are built in C:\Python27\Source\Python-2.7.10\PCbuild\amd64, rather than C:\Python27\Source\Python-2.7.10\PCbuild

Modules

The download includes the following modules - sorted alphabetically - that were more or less easy to build. Some of them are included because I use them in my professional life, some are included because they are fashionable, and some are included because people asked for them ;)

NameDescription
argparse 1.3.0
  • TODO: add description
beautifulsoup 4.3.2
  • beautifulsoup is another highly recommended screen scraping framework. Haven't used it myself, people made me do it...
  • New in document revision 4
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
boto 2.38.0
  • boto is an interface to the Amazon web services. I've been toying a bit with them on and off, but mostly off...
  • New in document revision 4
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
cffi 1.1.2
  • TODO: add description
Cheetah 2.4.4
  • Cheetah is a template engine and code generation tool.
  • Release build worked without any problem.
  • Debug build created a _namemapper_d.pyd, but did not install it.
  • python setup.py install created an .egg file. The problem with that was that once inside the egg, the Python C extension isn't loaded any longer. Solution: remove the .egg.
  • To verify that your build uses the C extension, use this:
    >>> import Cheetah
>>> Cheetah.__file__
'C:\\Python27\\lib\\site-packages\\Cheetah\\__init__.pyc'
>>> import Cheetah.NameMapper
>>> Cheetah.NameMapper.C_VERSION
True
  • Available in both the 32-bit and the 64-bit build
CherryPy 3.8.0
  • CherryPy is a minimalistic python web framework
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Document revision 4 updated the build version from 3.2.2 to 3.2.4
  • I modified the install to use a plain old cherrypy folder rather than the .egg folder
  • Available in both the 32-bit and the 64-bit build
construct 2.5.2
  • construct is a declarative parser/builder for binary data. I am a sucker for parsers, so I added it, even though I am oldschool enough to write my own, most of the time
  • New in document revision 4
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
cryptography 0.9.2
  • TODO: add description
cssselect 0.9.1
  • cssselect adds CSS selector support
  • New in document revision 4
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
Cython 0.22.1
  • cython is, quote, "an optimising static compiler for both the Python programming language and the extended Cython programming language". I am currently investigating whether this makes sense to me or not: I am undecided as of yet.
  • New in document revision 4
  • Available in both the 32-bit and the 64-bit build
dateutil 2.4.2
  • dateutil is, well, a date utility. Who doesn't like dates? And utilities? Whoa, I had to include it!
  • New in document revision 4
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
Django 1.8.2
  • Django is a "web framework for perfectionists with deadlines". I normally use CherryPy, but then my web framework needs are fairly minimal :)
  • New in document revision 4
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
dnspython 1.12.0
  • dnspython is a DNS toolkit for Python. I know, it is hard to believe with such a name!
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • document revision 4 updated the build version from 1.10.0 to 1.11.1
  • Available in both the 32-bit and the 64-bit build
flask 0.10
  • flask is a microframework for Python. Don't know what it does, really, but people wanted me to add it.
  • New in document revision 4
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
httplib2 0.9.1
  • httplib2 is a HTTP library, very much like the builltin httplib, with two important changes: it has a 2 at the end of the name, and it does more stuff. From this verbose description you can infer that I don't really know what it does, but people say it does whatever it does very good, so there.
  • New in document revision 4
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
itsdangerous 0.24
  • itsdangerous adds various helpers to pass trusted data to untrusted environments and back.
  • New in document revision 4
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
jinja 2.7.3
  • jinja is a python template engine. I am personally using Cheetah (see above), but jinja is the basis for flask, and since I am including flask, I more or less had to include jinja as well :)
  • New in document revision 4
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
lxml 3.4.4
  • lxml is, quote, "is the most feature-rich and easy-to-use library for processing XML and HTML in the Python language." It seems to have incredible traction (the number one download on pypi) but I am ashamed to say: I haven't ever used it.
  • This prooved to be a really shitty build.
  • lxml is based on libxslt and libxml2.
    • libxml2 uses libiconv.
      • libiconv has removed support for Microsoft compilers; however, there is this page that explains how to do it
      • Download the source associated with the article, rebuild libiconv, and you're good to go.
      • Now, head back to libxml2. libxml2-2.9.1\win32\Readme.txt contains detailed build instructions for Win32. I used the following options: cscript configure.js prefix=C:\Python27\Source\libxml2-2.9.1\win32\release incdir=C:\Python27\Source\libxml2-2.9.1\win32\release\include libdir=C:\Python27\Source\libxml2-2.9.1\win32\release\lib debug=yes include=C:\Python27\Source\libiconv-1.14\include lib=C:\Python27\Source\libiconv-1.14\Release_Win32
      • For the 64-bit build,make that Release_X64 rather than Release_Win32
      • I had to patch two files:
        • nanoftp.c needs these two defines at the top:
          #define SEND_ARG2_CAST
#define GETHOSTBYNAME_ARG_CAST
        • nanohttp.c needs this define:
          #define SEND_ARG2_CAST
      • Run nmake
      • Run nmake install
    • libxslt uses libiconv and libxml2. I did a bit of experimenting, then I used the following build parameters: cscript configure.js prefix=C:\Python27\Source\libxslt-1.1.28\win32\release incdir=C:\Python27\Source\libxslt-1.1.28\win32\release\include libdir=C:\Python27\Source\libxslt-1.1.28\win32\release\lib debug=yes include=C:\Python27\Source\libxml2-2.9.1\win32\release\include\libxml2;C:\Python27\Source\libiconv-1.14\include lib=C:\Python27\Source\libiconv-1.14\Release_Win32;C:\Python27\Source\libxml2-2.9.1\win32\release\lib
  • lxml is based on cython (and written by the same developers), but they encourage you to disable cython when building lxml. Quote:
    So, if you want a reliable build of lxml, we suggest to a) use a source release of lxml and b) disable or uninstall Cython for the build.
  • The initial build instructions failed to find libxml2. I had to patch setupinfo.py with this:
    _include_dirs.append(r"C:\Python27\Source\libxml2-2.9.1\win32\release\include\libxml2")
_include_dirs.append(r"C:\Python27\Source\libxslt-1.1.28\win32\release\include")
_include_dirs.append(r"C:\Python27\Source\libiconv-1.14\include")
_library_dirs.append(r"C:\Python27\Source\libxslt-1.1.28\win32\release\lib")
_library_dirs.append(r"C:\Python27\Source\libxml2-2.9.1\win32\release\lib")
_library_dirs.append(r"C:\Python27\Source\libiconv-1.14\Release_Win32")
_library_dirs.append(r"C:\Python27\Source\zlib-1.2.5")
  • Then I finally got it to build, for both debug and release, install it: and then the selftest fails. Because the install doesn't copylibexslt.dll, libiconv.dll,libxml2.dll or libxslt.dll.
  • Aaaaaaaaaaaaaaaaaaa! Did I mention it was a shitty build?
  • Available in both the 32-bit and the 64-bit build
Markdown 2.6.2
  • Markdown is a text-to-HTML conversion tool for web writers
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • document revision 4 updated the build version from 2.3.1 to 2.4.0
  • Available in both the 32-bit and the 64-bit build
MarkupSafe 0.23
  • MarkupSafe implements a XML/HTML/XHTML Markup safe string for Python
  • New in document revision 4
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
netaddr 0.7.15
  • TODO: add description
numpy 1.9.2
  • TODO: add description
pillow 2.9.0
  • pillow is a modern fork of PIL - which hadn't been updated in a couple of years.
  • New in document revision 4:
    • Support for FREETYPE2. Note that this was a bit of a hassle: the default setup.py did not find the freetype build 2.5.2 I had been using, so I had to fix the script a bit.
    • Support for LCMS2. Again this was a bit of a hassle: the default setup.py did not find the LCMS; building LCMS in turn required both libjpeg and libtiff: a never ending story. It works now :)
    • Support for LIBTIFF: 4 The TIFF component included a fixed reference to unistd.h in libimaging/tiffdecode.h: I just removed it and it built fine.
    • Support for WEBP (but not for WEBPMUX): Seriously though, I had neither heard of that format before nor have I ever used it. I am too old for this shit.
  • I modified the install to use a plain old PIL folder rather than the .egg zip archive
pip 7.1.0
  • pip is a tool for installing and managing Python packages.
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • document revision 4 updated the build version from 2.3.1 to 2.4.0
  • I modified the install to use a plain old pip folder rather than the .egg one
  • Available in both the 32-bit and the 64-bit build
psycopg2 2.6.1
  • psycopg is "that other" PostgreSQL wrapper for Python - besides PyGreSQL.
  • New in document revision 4
  • The debug build was broken: mt.exe was called on _psycopg.pyd, rather than _psycopg_d.pyd: quick and easy fix insetup.py
  • Available in both the 32-bit and the 64-bit build
py2exe 0.6.8
  • py2exe is a tool to convert python scripts to Windows executables. It works for me...
  • Build had to be run a couple of times, because of the dreaded manifest not found error. It built fine in the end, though.
  • Available in both the 32-bit and the 64-bit build
PyChart 1.39
  • pychart is a really old one (from January 1st 2006!) but it is a great small library to create PNG charts.
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
pycrypto 2.6.1
  • pycrypto is the python cryptography toolkit
  • Build experience (if such a thing exists) was great: it just works, and it includes proper builds for both debug and release.
  • Available in both the 32-bit and the 64-bit build
pyftpdlib 1.3.0
  • pyftplib is a super-fast and scalable FTP server library.
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • I modified the install to use a plain old pyftpdlib folder rather than the .egg zip archive
  • Available in both the 32-bit and the 64-bit build
pygments 2.02
  • TODO: add description
PyGreSQL 4.1.1
  • PyGreSQL is a PostgreSQL wrapper for Python. Note: There seems to be a tie with regards to recommendations of either pygresql or psycopg2, so I decided to include both in this release
  • I modified the install to use a plain old site-packages folder rather than the .egg zip archive
  • Make sure you have a PostgreSQL installation on your PATH
  • Build experience on 32-bit was great: it just works, and it includes proper builds for both debug and release.
  • Build experience on 64-bit had a small problem: there was no x64 debug build. I modified the source like this:
    #undef Py_InitModule4
#if PY_VERSION_HEX >= 0x02050000 && SIZEOF_SIZE_T != SIZEOF_INT
#ifdef _DEBUG
 #define Py_InitModule4 Py_InitModule4TraceRefs_64
#else
 #define Py_InitModule4 Py_InitModule4_64
#endif
#endif
  • Also, for 64-bit you need a 64-bit PostgreSQL installed.
  • Available in both the 32-bit and the 64-bit build (64-build is new for Document Revision 4)
pyodbc 3.0.10
  • pyodbc is a python ODBC wrapper
  • I had to patch setup.py: it removed --debug from the build args, thus effectively preventing the code from ever building a debug extension.
  • Available in both the 32-bit and the 64-bit build
pyOpenSSL-0.15.1
  • pyOpenSSL is another Python wrapper around OpenSSL, more suitable for network communication.
  • The build runs smooth by now. I didn't download a nightly build from the github repository, as those aren't documented in any way I could find.
pyserial 2.7
  • pyserial is a Serial Port IO library for Python
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
pywin32 219
  • pywin32 are the world-famous Windows extensions for Python.
  • Head over to sourceforge.net and download pywin32-219.zip, the latest source archive at the time of this writing.
  • Unzip it and place the sources folder relative to the Python-2.7.10 folder, as for all the other extension seen above.
  • Open a "Visual Studio 2010 Command Prompt" and navigate to the build directory (e.g. C:\Python27\Source\pywin32-219)
  • Do a python setup.py -q build
  • Note: many individual build steps fail with "manifest file not found". Just keep repeating the python setup.py -q buildmantra until it is done.
  • To build the 64-bit version, use setup.py build --plat-name=win-amd64
  • Available in both the 32-bit and the 64-bit build
queuelib 1.2.2
  • queuelib is a collection of persistent (disk-based) queues
  • New in document revision 4
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
reportlab 3.0
  • reportlab is an open-source PDF generation library
  • document revision 4 updated the build version from 2.6 to 3.0
  • Reqiured dependency on freetype, so I built that as well (in version 2.5.2)
  • Note: Version 2.6 didn't support a debug build, but version 3.0 does.
  • Had to patch the code for the 64-bit build to use the proper freetype library (was referring to win32 rather than to win64)
  • Available in both the 32-bit and the 64-bit build
requests 2.7.0
  • requests is "HTTP for humans", whatever that means.
  • New in document revision 4: a HTTP library for humans
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
Scrapy 1.0.1
  • scrapy is an open source web scraping framework. I wrote my own web scraping solution some years ago, but I am sure it was a lot less flexible ;)
  • New in document revision 4
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
setuptools 18.0.1
  • setuptools allows you to "easily download, build, install, upgrade, and uninstall Python packages". Well, OK.
  • The source archive includes pre-built .exe files. I don't know, but to a lay person like me it seems these won't work with a debug build. But then again, I've never used setuptools before, so I may be totally wrong...
  • I modified the install to use a plain old setuptools folder rather than the .egg zip archive
simplejson 3.7.3
  • simplejson is a fast, simple JSON wrapper for Python
  • document revision 4 updated the build version from 3.3.2 to 3.3.3
  • Build experience (if such a thing exists) was great: it just works, and it includes proper builds for both debug and release.
  • Available in both the 32-bit and the 64-bit build
six 1.9.0
  • six is a Python 2 and 3 Compatibility Library
  • New in document revision 4
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
SQLAlchemy 1.0.6
  • SQLAlchemy is a Python SQL toolkit and ORM. I am not using it personally, but lots of people seem to be
  • New in document revision 4
  • Build experience (if such a thing exists) was great: it just works, and it includes proper builds for both debug and release.
  • Available in both the 32-bit and the 64-bit build
twisted 15.2.1
  • twisted is an event-driven networking engine
  • New in document revision 4
  • Build experience (if such a thing exists) was great: it just works, and it includes proper builds for both debug and release.
  • Available in both the 32-bit and the 64-bit build
virtualenv 1.13.4
  • virtualenv is a "Virtual Python Environment builder", whatever that is.
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • document revision 4 updated the build version from 1.11.2 to 1.11.4
  • I modified the install to use a plain old virtualenv folder rather than the .egg one
  • Available in both the 32-bit and the 64-bit build
werkzeug 0.10.4
  • werkzeug is a python WSGI library required by Flask
  • New in document revision 4
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
wxPython 3.0.0
  • wxPython is the GUI for python. I can't believe this isn't part of the standard install (rather than the TCL/TK crap) but who am I to say?
  • I admit, I hesitated on that one. It always failed on me: the whole build process was really really messy. Which is a shame, since wxPython was nice to use - only I couldn't with my own Python build. So one day I decided to tackle this particular issue head on - and wrote a first version of this section.
    The build instructions in document revision 4 were fairly incomplete, which I found out the hard way when I tried to rebuild along those lines. Here now are instructions that are much more straightforward:
  • Unpack the source.
  • From the VC10 build prompt, do this:
    set WXWIN=C:\Python27\Source\wxPython-src-3.0.0.0
    (or wherever your source archive is)
  • copy %WXWIN%\include\wx\msw\setup0.h to %WXWIN%\include\wx\msw\setup.h. There is an argument in the readmes why this makes sense, but it doesn't convince me. We are in 2014, you know...
  • Go to %WXWIN%\build\msw
  • Do nmake /f makefile.vc BUILD=release SHARED=1. Notes:
    1. somehow the static build (with libs) didn't work with wxPython, so use the options given here...
    2. For the 64-bit build, do nmake /f makefile.vc BUILD=release SHARED=1 TARGET_CPU=X64
  • This part of the build should now complete without further issues.
  • Next, copy %WXWIN%\lib\vc_lib\mswu\wx\setup.h to %WXWIN%\include\wx
  • Go to %WXWIN%\wxPython
  • Do the python setup.py build dance.
  • The linker cannot find wxbase30u.lib. Well, there is one at %WXWIN%\lib\vc100_dll. Now if you look closely at the actual error message by the linker, you'll notice something:
    C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO 
<font color="#FF0000">/LIBPATH:..\lib\vcUNKNOWN_dll</font> /LIBPATH:C:\Python27\libs /LIBPATH:C:
\Python27\PC\VC6 wxbase30u.lib wxbase30u_net.lib wxbase30u_xml.lib wxmsw30u_core.lib wxmsw30u_adv.lib
wxmsw30u_html.lib kernel32.lib user32.lib gdi32.lib comdlg32.lib winspool.lib winmm.lib shell32.lib
oldnames.lib comctl32.lib odbc32.lib ole32.lib oleaut32.lib uuid.lib rpcrt4.lib advapi32.lib wsock32.lib
/EXPORT:init_core_ build\temp.win32-2.7\Release\src/helpers.obj build\temp.win32-2.7\Release\src/wxc.res
build\temp.win32-2.7\Release\src\msw\_core_wrap.obj /OUT:T:\wxPython-src-3.0.0.0\wxPython\wx\_core_.pyd
/IMPLIB:build\temp.win32-2.7\Release\src\_core_.lib /MANIFESTFILE:build\temp.win32-2.7\Release\src\_core_.pyd.manifest
    Now, in document revision 3 I suggested simply renaming the DLL, but there is a better option: edit config.py and change the two lines highlighted below:
    def getVisCVersion():
    text = getoutput("cl.exe")

    if 'Version 13' in text:
        return '71'
    if 'Version 15' in text:
        return '90'
    <font color="#FF0000">if 'Version 16' in text:
        return '100'</font>
    # TODO: Add more tests to get the other versions...
    else:
        return 'UNKNOWN'
  • Note: for the 64-bit build, the linker refers to vc_dll rather than vc_x64_dll. There is an easy way out: remove your existing vc_dll folder, and rename vc_x64_dll to vc_dll instead. I know, it's a hackers solution, but it works...
  • Repeat the build - and it'll fail again. So I added this to config.py:
    libdirs = [ opj(WXDIR, 'lib', VCDLL), r"C:\Python27\Source\wxPython-src-3.0.0.0\lib\vc_dll"]
  • Repeat the build. It should work by now.
  • Finally, install the files using python setup.py install
  • Now, if you want the debug build, go back to %WXWIN%\build\msw
  • Do nmake /f makefile.vc SHARED=1 (without the BUILD=release option; add TARGET_CPU=X64 for the 64-bit build)
  • Go to %WXWIN%\wxPython
  • Do python_d setup.py build --debug dance.
  • Do python_d setup.py build --debug install dance.
  • Finally, as per usual, I moved the files from the .egg to the oldschool wx folder.
  • Oh, and obviously don't forget to include the wxPython DLLs themselves in the wx folder!
w3lib 1.5
  • w3lib is a library of web-related functions
  • New in document revision 4
  • Project doesn't use C/C++ extensions, so it isn't necessary to build two separate Debug/Release builds
  • Available in both the 32-bit and the 64-bit build
zope.interface 4.1.0
  • zope.interface adds "Interfaces" to Python
  • New in document revision 4
  • Available in both the 32-bit and the 64-bit build

Verifying you are using the updated SSL versions:

Python 2.7.10 (default, Jul  6 2015, 11:26:50) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import OpenSSL
>>> import OpenSSL.SSL
>>> OpenSSL.SSL.SSLeay_version(OpenSSL.SSL.SSLEAY_VERSION)
'OpenSSL 1.0.1p 12 Jun 2015'
>>> ....
>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 1.0.1p 12 Jun 2015'

Back to the build overview

Document history

  • August 7, 2015: document revision 8
    • Provided builds using Visual Studio 2015
    • Updated OpenSSL to 1.0.2d
  • July 12, 2015: document revision 8
    • Updated OpenSSL to 1.0.1p
  • July 6, 2015: document revision 7
    • Updated Python to 2.7.10
    • Updated OpenSSL to 1.0.1o
    • Updated a ton of other modules
  • May 10, 2015: document revision 6
    • Updated Python to 2.7.9
    • Updated OpenSSL to 1.0.1m
    • Updated PILLOW to 2.8
  • April 12, 2014: document revision 5
  • March 8, 2014: document revision 4
    • Added a detailed section on Debug / Release builds, and how to get those.
    • Added x64 build for all components (and x64 build notes for all)
    • Added tons of debug versions (for example, for win32api)
    • Added many new libraries (for example, SQLAlchemy, psycopg2, beautifulsoup, and others.)
    • Generally, resolved .eggs as standard folders - a matter of personal preference
  • Feb 24, 2014: document revision 3
    • Added wxPython 3.0.0
  • Feb 23, 2014:: document revision 2
    • Enabled TCL/TK build
    • OpenSSL updated to 1.0.1f
    • SQLite updated to 3.8.3.1
  • Jan 5, 2014: First release




posted @ 2015-09-02 22:51  Jonn.  阅读(626)  评论(0)  编辑  收藏  举报