Print

[Sob]

I decided to upgrade my Apache to x64 version. ApacheHaus satisfied my need for almost all extra modules, but there were some exceptions, most notable being SubVersion. I tried to ask Uncle Google for it, but had no luck and I'm usually very successful when googling for something.
My rule is to try to solve things myself first, rather than asking someone and then waiting (possibly forever for reply. So I tried to compile it myself and after solving few small problems, I ended up with something that seems to work.
But still it would feel a little better if there were some binaries made by someone who really understands it, tested by many users, etc.. you know what I mean. So, did I miss some obvious source or am I wandering in to unexplored lands?

[mario]

Well I tried to compile it, but I wasn't able to compile it 
Tell me how you did it and than I can try it by myself.

[Sob]

I needed only Apache modules, nothing else, so I omitted some prerequsities for client part. Complete SubVersion will not build using the following instructions. Also I needed only FSFS storage for SubVersion, I skipped BDB completely.

- Download and unpack SubVersion source (I used latest 1.6.12).
- Download and unpack SQLite amalgamation to "sqlite-amalgamation" subdirectory.
- Download and unpack ZLIB to "zlib" subdirectory.
- Create empty subdirectory "neon".
- Run (for VS2008): gen-make.py -t vcproj --vsnet-version=2008 --with-httpd=path-to-your-configured-httpd-source

First problem: ZLIB build must be fixed for x64, otherwise there will be one unresolved external symbol later. Quick fix is to open build\win32\build_zlib.bat and insert this at line 51:
set ASM_OPTS=AS=ml64 LOC="-DASMV -DASMINF" OBJA="inffasx64.obj gvmat64.obj inffas8664.obj"
(info found in zlib\win32\Makefile.msc) and then open zlib\contrib\masmx64\inffas8664.c and prepend "../../" to four includes at the beginning.

- Open subversion_vcnet.sln in VS and select Release x64
- Select mod_authz_svn and build it, all required dependencies will be built automatically

Second problem: there will be a lot of unresolved external symbols. I added following include paths and input files for linker:

for mod_dav_svn:

..\..\..\Release\subversion\libsvn_delta
..\..\..\Release\subversion\libsvn_fs
..\..\..\Release\subversion\libsvn_fs_fs
..\..\..\Release\subversion\libsvn_fs_util
..\..\..\Release\subversion\libsvn_repos
..\..\..\Release\subversion\libsvn_subr

xml.lib
Crypt32.lib
svn_delta-1.lib
svn_fs-1.lib
libsvn_fs_fs-1.lib
libsvn_fs_util-1.lib
svn_repos-1.lib
svn_subr-1.lib

for mod_authz_svn:

..\..\..\Release\subversion\libsvn_repos
..\..\..\Release\subversion\libsvn_subr

svn_repos-1.lib
svn_subr-1.lib

- After that build should succeed and resulting Apache modules are:

Release\subversion\mod_authz_svn\mod_authz_svn.so
Release\subversion\mod_dav_svn\mod_dav_svn.so

SubVersion is linked in statically. The usual 32bit version uses external dlls, but I wasn't able to build it this way. Not really a problem for me, as there won't be anything else on the same server that could share the dlls anyway.
As I mentioned, the resulting modules seem to work fine, but is everything really ok or is there any hidden problem waiting to show itself in the worst possible time? Who knows..

[mario]

I'll try that this night or in this week or weekend.

At least for  zlib-1.2.4 you don't have to modify the source code.

Code: [Select]

nmake -f win32\Makefile.msc


[Gregg]

I'm glad to see a fix for zlib 1.2.5. Thanks Sob, I am surprised I did think to try that. And if this is the Sob of that APR adjustment for IPv6 on XP/2003, even bigger thanks as we've gotten a lot of use out of it.

[mario]

OK, -t vcproj --vsnet-version=2008 was the hint I needed  I gonna try that modules this night when I'm home.

[Sob]

Zlib 1.2.5 removed inffast.obj from linker input in default (non-ASM) build and it fails with unresolved external symbol inflate_fast. It works with:

Code: [Select]

nmake -f win32/Makefile.msc OBJA=inffast.objFor x64 ASM build there's whole new command line (written conveniently only at the top of Makefile.msc; but if you're wondering why the @#$%! thing doesn't compile, you'll look there sooner or later ). And it almost works, you just need to fix one name (inffas8664.c should be inffas8664.obj) and then either move inffas8664.c to source root and change the path in Makefile.msc OR leave it where it is and prepend "../../" to includes OR the best solution I tried now, use this command line:

Code: [Select]

nmake -f win32/Makefile.msc AS=ml64 LOC="-DASMV -DASMINF -I." OBJA="inffasx64.obj gvmat64.obj inffas8664.obj"
build_zlib.bat is generated by SubVersion's gen-make.py and it was either not tested with zlib 1.2.5 and/or x64 build, so it just needs a little adjusting to use proper parameters to nmake.

Gregg> Yep, I'm that Sob. But really, those three lines of actual code are nothing.

[Gregg]

It's not the # of lines, you obviously took some time tracking down why the problem existed and where the best place to fix it was. For that, you get the thanks! 

[Gregg]

Code: [Select]

nmake -f win32/Makefile.msc AS=ml64 LOC="-DASMV -DASMINF -I." OBJA="inffasx64.obj gvmat64.obj inffas8664.obj"

Awesome, worked perfect.

[mario]

Second problem: there will be a lot of unresolved external symbols. I added following include paths and input files for linker:

I didn't have to do that. Cause I downloaded subversion-1.6.12.tar.bz2 and subversion-deps-1.6.12.tar.bz2 which also includes neon. But I used the already compiled OSSL and zlib from the apache source tree. Also the OSSL in the apache source tree is much newer than the one from the deps archive.

What a pitty that I forgot my laptop at work with the compiled binaries, so I can't test my build right now.   

[mario]

It works! At least for me. You may try it dev.mariobrandt.de/mod_svn.7z I tested on w2k8 R2 and Win7 x64 Ultimate

[Sob]

I missed deps package, but the rest of my minimalistic approach was intentional. Nothing really complained, but clearly it wasn't the best thing to do.

So it seems that SubVersion for Apache x64 is well prepared from the original developers. With only little exception for changed command line to compile newest zlib. Good news.

[Gregg]

Mario,

We going to offer it? Can you do a x86 version as well?
How often does it change?

Seems to me your sitting on a x64 PHP too no?

That reminds me, there's a new mod_bw ... I plan to build this weekend and put up.

[mario]

yepp I gonna try x86 version next week too. Now I've tested the x64 version and I think it is stable enough to offer it.

Well the x64 PHP is still not working as I'd like it. e.g. mcrypt does not work at all.To make it more confusing there is no error message that the module don't load O_o. And the php5apache2_2 does not work yet. But it runs stable for weeks now for fcgid on a real server.

[mario]

Reminder to myself: a 32 bit module does not compile with 64 bit zlib and 64 bit ossl