On 6/22/2016 2:01 PM, Cooke, Mark wrote:
-----Original Message-----
From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: 22 June 2016 12:38
Hi Mark,
Folks,
We use subversion with Trac behind httpd on Windows Server. As Trac is
written in "old" Python (2.x), I have had to resort to building everything
from source. This is not simple and so I thought I would publish my notes
here in case it helps anyone else and in the hope that if I have made any
mistakes, someone will be kind enough to point them out to me!
~ Mark C
These are my notes for building Apache httpd and subversion for use with
Trac [1]. All of the components need to be built using the same compiler to
avoid run-time issues and, since Trac currently relies on Python 2.x, that
means Visual Studio 2008.
Why does Python 2.x (aka: 2.7.11) imply having to use VS 2008? MaxSVN
[1] is built using VS 2015 Update 1 (the upcoming builds will use VS
2015 Update 2) in combination with Python 2.7.11 and I'm unaware of any
issue related to that.
[1] http://www.luke1410.de/typo3/index.php?id=97
I cannot remember specific references now but when I looked into this before it
is because the official 2.x line is compiled using VC9. When memory is passed
between applications relying on different version of the CRT then you can end
up with hard to diagnose memory corruptions that eventually cause problems.
This is correct. If you are building a project linking in the CRT, you
should ensure that all DLLs and libraries you build with use the same
CRT. Mixing different CRT versions is unsupported and you will have
undefined behavior. The possibilities for memory corruptions is the most
prominent effect one might observe, but there are other problems/issues
this will cause too.
Digging a bit I found this thread [1] that highlights a similar CRT issue in
python modules such as psycopg2 (which I use for PostGreSQL) that use the CRT
internally...
[1] https://groups.google.com/forum/#!topic/modwsgi/ATtKX6qWLXc
As far as I skimmed through the thread the problem here is not with
python being compiled using VC9, but rather the module the python script
tries to load (psycopg2, which according to the web seems to be some
postgre-sql-related library) was compiled with a different CRT than the
Apache binaries. That's a general issue, yes, and that's why I don't
distribute the svn-apache modules with MaxSVN, even though they are
built as part of the buildprocess (and utilized for testing). It's
imperative that the CRT for the Apache modules matches the ones used to
build Apache and that only the distributor of the specific Windows
Apache module can ensure.
If you can guarantee to me that isn't going to happen then it would make my
life easier!
I might miss something here which exceeds my knowledge (tbh I've only
average experience with Apache httpd and python), but as long as there's
nothing pulled in from python when you build Apache (and I'm quite sure
that's not the case), python is just used as a build tool (for building
SVN, Apache) and lateron as a script tool (from Apache). It doesn't
matter how the python executable is build in this regard and which CRT
it uses. It however matters a lot for the modules you'd pull in with the
python import statement.
Regards,
Stefan Hett
