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

阅读量：4961 次

发布时间：2019-06-12

本文共 34727 字，大约阅读时间需要 115 分钟。

您的浏览器(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:

Name	Visual Studio 2010	Visual Studio 2015
Python 2.7.10 32-bit
Python 2.7.10 32-bit Sources
Python 2.7.10 64-bit
Python 2.7.10 64-bit Sources

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:

It is a very bad idea to mix different Visual C++ runtimes. See for an explanation. This means if you use the official libraries to link in Python, you are in for some nasty surprises.

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 . At the time of this writing, Python 2.7.10 is the official release, so I will use 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 .

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:

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

Well, 3.6.21 is old – it . 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:

So first we’re going to update sqlite. No risk, no fun! Head over to and download the latest amalgamation sources; at the time of the writing these were . 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 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 .

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:

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

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  kernel32.lib user32.lib ws2_32.lib @C:\Users\Gerson\AppData\Local\Temp\nmFA32.tmpPython-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.tmpPython-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:cvtcl-8.5.2.1/win/makefile.vc:@LDFLAGS_DEBUG@      -nologo -machine:$(MACHINE) -debug:full -debugtype:cvtcl-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:cvtk-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:

Run notepad Tools\buildbot\external.bat and replace DEBUG=1 with an empty string.

Still in notepad, replace tcl85g.dll with tcl85.dll, and tk85g.dll with tk85.dll

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, 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 directory19>  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
```
         
```
to
```
         
```

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:

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

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.

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.

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 ;)

Name	Description
argparse 1.3.0	TODO: add description
beautifulsoup 4.3.2	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	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	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_VERSIONTrue Available in both the 32-bit and the 64-bit build
CherryPy 3.8.0	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	is a declarative parser/builder for binary data. I am , 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	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	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	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	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	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	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	is a HTTP library, very much like , 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	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	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	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, 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 copy`libexslt.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	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	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	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	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	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 in`setup.py` Available in both the 32-bit and the 64-bit build
py2exe 0.6.8	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	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	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	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	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	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	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	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	are the world-famous Windows extensions for Python. Head over to 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 build`mantra 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	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	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	is "HTTP for humans", whatever that means. 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
Scrapy 1.0.1	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	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	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	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	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	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	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	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	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: somehow the static build (with libs) didn't work with wxPython, so use the options given here... 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 /LIBPATH:..\lib\vcUNKNOWN_dll /LIBPATH:C:\Python27\libs /LIBPATH:C:\Python27\PC\VC6 wxbase30u.lib wxbase30u_net.lib wxbase30u_xml.lib wxmsw30u_core.lib wxmsw30u_adv.libwxmsw30u_html.lib kernel32.lib user32.lib gdi32.lib comdlg32.lib winspool.lib winmm.lib shell32.liboldnames.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.resbuild\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' if 'Version 16' in text: return '100' # 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	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	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 win32Type "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'

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
- Updated OpenSSL to 1.0.1g for fix of

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