> -----Original Message----- > From: Stefan Hett [mailto:ste...@egosoft.com] > Sent: 22 June 2016 17:03 > > On 6/22/2016 5:30 PM, Cooke, Mark wrote: > > > >> -----Original Message----- > >> From: Stefan Hett [mailto:ste...@egosoft.com] > >> Sent: 22 June 2016 13:25 > >> > >> 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). > > Certainly that's working. But since you are recompiling psycopg2 > yourself, why don't you just recompile that then using VS 2015? Or are > there other python libs involved?
I am not compiling python or any of the support libs that we use, I decided to compile httpd and svn instead. I will have another go with VisualSVN again to see if it works for us now. > -- > Regards, > Stefan Hett
