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
For the impatient:
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:
Wraps 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 in pyproject.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
and download the latest
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 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
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:
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
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
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& /&
&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:
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 in PCBuild: 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
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 pe)
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_VERSION
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 M 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 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
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
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 &= 0x && SIZEOF_SIZE_T != SIZEOF_INT
#ifdef _DEBUG
#define Py_InitModule4 Py_InitModule4TraceRefs_64
#define Py_InitModule4 Py_InitModule4_64
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 )
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
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
&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...
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 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!
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 win32
Type &help&, ©right&, &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
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