Comments on: Making a Trac install work on Apache 2.2/Python 2.6/win32, 2010 edition

By: cercatrova

cercatrova — Sun, 28 Mar 2010 15:12:02 +0000

Understood – that would explain it. And I see now that the mod_python compilation guide is from somebody else (sorry for the confusion).

By: Lars Erik Jordet

Lars Erik Jordet — Sun, 28 Mar 2010 13:47:52 +0000

Not sure why the other version is different; my version is produced and named by the build script, so there was no “conscious choice” by me to name it 3.3.2.

By: cercatrova

cercatrova — Sun, 28 Mar 2010 13:30:37 +0000

Thanks for your help with mod_python and python 2.6. Perhaps you’re already aware of it, but you’d probably make a lot of people happy if you figured out the PSP mod_python compilation problem and somehow got the installer posted to the Apache mod_python site. Also, are you labeling it mod_python 3.3.2 because of the fix in the trunk that you mention? And just out of curiosity, do you know why there is an identically named exe file (with a much different size) at http://www.hydra1983.com/?p=1508?

By: Lars Erik Jordet

Lars Erik Jordet — Wed, 24 Feb 2010 09:47:44 +0000

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.

By: Joel Low

Joel Low — Mon, 15 Feb 2010 08:36:50 +0000

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…

By: Lars Erik Jordet

Lars Erik Jordet — Mon, 15 Feb 2010 07:27:35 +0000

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.

By: Joel Low

Joel Low — Mon, 15 Feb 2010 07:20:03 +0000

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.