> -----Original Message----- > From: Stefan Hett [mailto:ste...@egosoft.com] > Sent: 22 June 2016 13:25 > To: users@subversion.apache.org > Subject: Re: Compiling svn + httpd for windows python 2.x > > 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.
...and that is my problem: Trac is running under py2.7 (via mod_wsgi from httpd) and using psycopg2 to connect to a PostGreSQL backend. AFAIK, python 2.7.x windows extensions should be built using VC++ 2008 to match the python build, so it is best if I build httpd, mod_wsgi and svn using that compiler too (especially as local policy means I need to be able to apply the latest e.g. OpenSSL updates as they come out). > > 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. Hmm, I started down this path because I had problems and I think they were as mentioned above. Life was good when Apache provided VC9 windows binaries and I could get svn with the python bindings from alagazam... ~ Mark C > Regards, > Stefan Hett
