trac svn-python mismatch with apache 2.2 under windows

[jschmidt@…]

If you use xampp apache 2.2 and trac 11b1, you have to use the svn-python binding from this page (binding for apache 2.0) http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91&expandFolder=91&folderID=74 Subversion recommended this binding http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=8100&expandFolder=8100&folderID=8100 But in this case I have an unsynchronized repository. error-stack:

2008-01-30 12:21:21,890 Trac[svn_fs] INFO: Failed to load Subversion bindings
Traceback (most recent call last):
  File "C:\Python25\Lib\site-packages\trac\versioncontrol\svn_fs.py", line 251, in __init__
    _import_svn()
  File "C:\Python25\Lib\site-packages\trac\versioncontrol\svn_fs.py", line 69, in _import_svn
    from svn import fs, repos, core, delta
  File "C:\Python25\Lib\site-packages\svn\fs.py", line 19, in <module>
    from libsvn.fs import *
  File "C:\Python25\Lib\site-packages\libsvn\fs.py", line 29, in <module>
    import core
  File "C:\Python25\Lib\site-packages\libsvn\core.py", line 5, in <module>
    import _core
ImportError: DLL load failed: Die angegebene Prozedur wurde nicht gefunden.

So I go back to use the binding for apache 2.0. If you follow the install-guide from Trac, you won't realize this mistake, because the link brings you to subversion/apache 2.0. Please resolve this mismatch!

[anonymous]

<<If you follow the install-guide from guide>> has to be 'from trac' 8)

[cboos]

Which part of the install guide?

At least, the TracOnWindows#using-installers part seems clear enough about this.

OTOH, the next section (manual install) still needs much cleanup/removal.

[jschmidt@…]

In this part of the guide TracOnWindows#using-installers the link of the subversion-python 2.5 binding points on a apache 2.0 version. I installed Apache 2.2 and downloaded the corresponding version directly from tigris.

[cboos]

Ok, so you haven't read the associated notes ;-)

[anonymousjschmidt@…]

I think the problem is, that tigris offer the svn-binding as a working exe, which is not. so let's close the ticket and I will send this ticket to the subversion developers, because they have to recover their bindings and not the trac-ians, isn't it?

[cboos]

Ok, sorry, I didn't get it at first.

So you're basically saying that the Subversion 1.4.6 bindings for Apache 2.2 are actually not compatible with Apache 2.2, but that the Subversion 1.4.6 bindings for Apache 2.0 are?

That's weird. Though I haven't tried myself, I doubt this. From the Apache 2.2 page:

Windows binaries built against Apache 2.2.x -- note that Apache 2.2.4 or higher is required.

Have you checked whether the xampp Apache 2.2 satisfies this requirement?

[jschmidt@…]

Yes, I checked: I'm using the newest release xampp 1.6.5 with Apache 2.2.6

[Laurens Blanckenborg <laurens@…>]

My experiences in this matter are even wierder.

I encountered the same error as mentioned above. I tried to get Trac working under Apache 2.2.8 with mod_python. I have installed (binary releases) Apache 2.2.8 from ApacheLounge? (compiled with VC2008), ActivePython? 2.5.2.2, mod_python 3.3.1 from apache.org and the svn-bindings from subversion.tigris.org (the ones compiled against 2.2).

Though everything installed without a problem, the mod_python testhandler showed that mod_python was functioning OK and both my existing trac-envs as well as the newly created test-environment ran fine under the standalone tracd, I was not able to browse the repo when accessing the envs via mod_python. The traclog returned the same error as stated above.

I read the remarks in the help/guide about adding the bindings (./svn and ./libsvn) to the pythonpath, but that didn't help. When testing if using Apache 2.0 would solve the problem (with the appropriate 2.0-mod_python and 2.0-bindings) I accidentally got it working under 2.2.

The following weird mixing did the trick: ActivePython? 2.5.2.2 (not changed when going back to 2.0); uninstalled svn-python and mod_python for 2.2; installed svn-python for Apache 2.0; installed mod-python for Apache 2.0 *** BUT *** loaded the Apache-modulefile (mod_python.so) from the 2.2-package. Now I can browse the repo via mod_python under Apache 2.2.8.

Using the 2.0-mod_python.so under Apache 2.2.8 causes it to fail starting the service, using the whole mod_python2.2-package together with the bindings for 2.0 (as mentioned above) causes Trac in import the bindings, but Trac then stops after importing the bindings (giving a blank page and leaving "[...] Trac[svn_fs] DEBUG: Subversion bindings imported" as the last line in the log).

I really don't know a possible cause of this wierd behavior, but I hope some other people could benefit from my experience as it took me several days searching the internet to get it all working.

Remark: I'm using Windows Server 2003 x64 SP2, but all software (Python, Apache, SVN) is 32bit. I don't think this error to have anything to do with x64.

[cboos]

Thanks a lot for your detailed explanation, I'll add a link to it at the relevant places.

I think this whole story can be explained by mismatched MSVCRTs. You could have a look at the various .exe, .so and .pyd files involved here using the dependency walker (depends.exe) and see to which MSVC runtime each is linked to.

Off-topic note to self: [...] should not be recognized as a relative wiki link...

[ebekker4csc@…]

More info on this issue. We experienced the exact same problem, here is our setup: VisualSVN Server (Apache 2.2.9), with the latest bins for Python 2.5, SVN 1.5, SVN-Python (SVN1.5-Py2.5-Apache2.2), mod_python-3.3.1 (Apache 2.2), Trac 0.11.

Just as in your case, we could run tracd with no problems, but when running through Apache (VisualSVN Server) we got the same error trace failing to load _core. We solved it by replacing the libapr-1.dll in the Apache bin with the version that's in Python's libsvn, just substituting seems to have fixed it.

Using the "depends" utility we see that one specific routines symbol name has changed, specifically "_apr_time_ansi_put@12" became "_apr_time_ansi_put@8" and libsvn has a dependency on the latter. Looks like this is an issue for the SVN guys to fix, but I'm curious how the signature for this routine changed between the builds?

[sakesun]

We experienced the exact same problem as ebekker4csc

and the solution mentioned solve the problem.

We solved it by replacing the libapr-1.dll in the Apache bin with the version that's in Python's libsvn, just substituting seems to have fixed it.

Thanks

[wtigotw]

Same setup, same problem, same solution as the other two

Replying to sakesun:

We experienced the exact same problem as ebekker4csc and the solution mentioned solve the problem.

We solved it by replacing the libapr-1.dll in the Apache bin with the version that's in Python's libsvn, just substituting seems to have fixed it.

Thanks