About 10 months ago I wrote a short article on getting Trac to work on Python 2.6 and Windows. Recently I updated the install, and took a look at how the situation is now.
This guide assumes you have a working install of Trac on Python 2.5/mod_python/Apache2.2 already, as described in the Trac install guide, and that Python 2.6 is installed.
What needs to be done:
- Install Python 2.6 and Trac for 2.6
- Build a new version of mod_python
- Optionally Replace Apache DLLs (mostly if you followed my previous guide)
Required software
You’ll need Visual C++ 2008 Express Edition or any retail version of VS 2008 if you want to build your own mod_python for 2.6 (I’ll provide a precompiled one in this post).
Preparing
Install Python 2.6 and Trac on 2.6 (using “ easy_install trac” is recommended)
You’ll probably also want to easy_install Pygments for source highlighting.
Building mod_python for 2.6
This guide to mod_python covers the creation and installation of a compatible version of the module.
At this point, you should be able to restart Apache and load up your “old” Trac on Python 2.6, but with the error message that “svn” support is not installed.
A pre-built version of this can be found here: mod_python-3.3.2-dev-20080819.win32-py2.6.exe
Python SVN bindings
My old guide had instructions on how to build these yourself, but after that article was made, “official” Python 2.6 bindings have been released.
Most recent version as of this writing is the SVN 1.6.6 version of the bindings.
Replacing Apache DLLs to make libsvn work
Note: Only use these instructions if you experience problems, and/or you’re running a self-built version of the Python SVN bindings already.
There’s a slight difference between libapr-1.dll as supplied with Apache 2.2 and the one we built together with libsvn, so the fix is to replace the one in your Apache2.2\bin folder with the one from your Python2.6\Lib\site-packages\libsvn folder (copy the libsvn_*.dlls from the same folder into the Apache2.2\bin folder if you still get problems).
Restarting Apache now should make Trac work fully, with Subversion support.
Joel Low
on Feb 15th, 2010
@ 08:20:
Thanks for the help you’ve provided with this (and the previous) articles! I think I’ve found the reason that we need to replace libapr-1.dll — there’s a signature mismatch.
In the trac ticket you mentioned, someone did nail it down to a change in the declaration of _apr_time_ansi_put (@12 vs @8, which took me 4 hours to nail down, urgh!) The declaration of apr_time_ansi_put takes a time_t argument, which until VS2005 was typedef’ed to an int; after which was typedef’ed to an long long. Thus, the size of time_t changed between versions of VS. Since we’re compiling on VS2008, time_t defaults to 8 bytes (64 bits)
Since the compiler tacks on the size of the arguments to the function to the end of the function (the @x bit) our VS2008 declaration has a different name from the one declared in libapr-1.dll (which, presumably is compiled on an earlier version of VS). This results in our entry point not found error when using the binaries from within Apache (because, since the httpd’s libapr-1.dll is already loaded in memory space, when the svn-python dlls import libapr-1.dll, they get the httpd copy and not our own)
Hence, I would imagine a better solution would be to define _USE_32BIT_TIME_T (see: http://msdn.microsoft.com/en-us/library/4wacf567.aspx) when building the projects which reference time_t (which is most of the SVN libraries) It’s really tedious, so one may decide to modify the VS header files to define that preprocessor variable and remove it when we’re done compiling svn-python.
Lars Erik Jordet
on Feb 15th, 2010
@ 08:27:
Yep, it looked like a signature mismatch, but I didn’t really care enough to trace the exact reason for the problem when replacing libapr-1.dll worked
I could probably whip up a build script to automate most of the process, but it looks like the “official” SVN-python bindings are being kept up-to-date now.
Joel Low
on Feb 15th, 2010
@ 09:36:
For the record, I found that a slightly less intrusive way (on the runtime, anyway) would be to use Property Sheets to define _USE_32BIT_TIME_T instead.
Yes, while the official bindings are built, I am yet to see 1.6.9’s — it’s been nearly a month! I needed the binaries for a few servers so I decided to spend time and build it myself…
Lars Erik Jordet
on Feb 24th, 2010
@ 10:47:
I’ll have to try building the bindings again sometime soon, and update the article. I have a “clean” computer I use for these things, to make sure I have 100% control over the prerequisites.
I’m not sure if I should just start posting my compiled versions (potentially wrapped in a nice installer) here.