[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: Stefan Hett <stefan_at_egosoft.com>
Date: Wed, 22 Jun 2016 18:03:03 +0200

On 6/22/2016 5:30 PM, Cooke, Mark wrote:
>
>> -----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).
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?

-- 
Regards,
Stefan Hett
Received on 2016-06-22 18:03:15 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.