[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Compiling svn + httpd for windows python 2.x

From: Cooke, Mark <mark.cooke_at_siemens.com>
Date: Wed, 22 Jun 2016 15:30:34 +0000

> -----Original Message-----
> From: Stefan Hett [mailto:stefan_at_egosoft.com]
> Sent: 22 June 2016 13:25
> To: users_at_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:stefan_at_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
Received on 2016-06-22 17:30:51 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.