subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cooke, Mark" <mark.co...@siemens.com>
Subject RE: Compiling svn + httpd for windows python 2.x
Date Wed, 22 Jun 2016 17:13:30 GMT
> -----Original Message-----
> From: Stefan Hett [mailto:stefan@egosoft.com]
> Sent: 22 June 2016 17:03
> 
> On 6/22/2016 5:30 PM, Cooke, Mark wrote:
> >
> >> -----Original Message-----
> >> From: Stefan Hett [mailto:stefan@egosoft.com]
> >> Sent: 22 June 2016 13:25
> >>
> >> On 6/22/2016 2:01 PM, Cooke, Mark wrote:
> >>>> -----Original Message-----
> >>>> From: Stefan Hett [mailto:stefan@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


Mime
View raw message