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:
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 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.
- 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 use Python-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 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 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:
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 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:
- 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, 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:
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
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 |
|
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 |
|
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 |
|
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:
- 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 |
- 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 |
|
numpy 1.9.2 |
|
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 in setup.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 |
|
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 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 |
- 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:
- 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...
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
.egg
s as standard folders - a matter of personal preference
- Feb 24, 2014: document revision 3
- 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