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? :)
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.
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.. :)
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.
nmake -f win32\Makefile.msc
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.
OK, -t vcproj --vsnet-version=2008 was the hint I needed :) I gonna try that modules this night when I'm home.
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:
nmake -f win32/Makefile.msc OBJA=inffast.obj
For 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:
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. :)
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! :)
Quote from: Sob on August 31, 2010, 07:19:02 PMnmake -f win32/Makefile.msc AS=ml64 LOC="-DASMV -DASMINF -I." OBJA="inffasx64.obj gvmat64.obj inffas8664.obj"
Awesome, worked perfect.
Quote from: Sob on August 31, 2010, 04:40:38 PM
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. :-\
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
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.
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.
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.
Reminder to myself: a 32 bit module does not compile with 64 bit zlib and 64 bit ossl
Ok build is done :)
With this x86 package I made only the load test and some commits.
dev.mariobrandt.de/mod_svn_x86.zip
I guess I have to write a readme.1st.txt for both (x86 and x64) if not another one do it... when done I will put it on the mirrors, since the x64 version works now since a week under usage.
Mod svn is now as 32bit and 64bit on the download page.
Today I built 1.6.13
Gonna test it and than up it to the download area
All tests went fine. There is it on the download page (http://www.apachehaus.com/cgi-bin/download.plx)
In both the 32-bit and 64-bit versions, I am unable to run the included svn.exe and svnsync.exe. They complain about missing ordinal 132 in ssleay32.dll. I tried updating to the openssl 1.0.0c stuff which does not appear to help. svnadmin.exe, svnlook.exe, and svnversion.exe appear to run fine. Am I doing anything wrong? (I originally downloaded the non-sni apache version for each platform.)
The mod_dav_svn module itself appears to work great and I really appreciate it being built!
I tested it today on a brand new installed XP without a problem (32bit version). it would be nice to have the error messages from the windows event log and a screenshot from that message if it is a popup.
Which OS do you run?
Quote from: mario on December 18, 2010, 07:03:50 PM
I tested it today on a brand new installed XP without a problem (32bit version). it would be nice to have the error messages from the windows event log and a screenshot from that message if it is a popup.
Which OS do you run?
Tried on both Win XP (32-bit) and Win 7 (64-bit). The windows popup says: "The ordinal 132 could not be located in the dynamic link library SSLEAY32.dll."
(not sure how to attach a screen shot) Nothing in the windows event log that I could find.
Do you have any other ssleay32.dll files on your system path that svn.exe may be picking up before the one from the apache bin directory?
Using depends.exe from http://www.dependencywalker.com/ I show that the ssleay32.dll file included with the apachehaus zip file is indeed missing ordinal 132 so it would appear that svn.exe is linked against a different ssleay32.dll than the one shipped with apachehaus.
On my Windows 2008 R2 I'm able to reproduce that error. I gonna try out how to solve that.
Quote from: mario on December 18, 2010, 07:52:12 PM
On my Windows 2008 R2 I'm able to reproduce that error. I gonna try out how to solve that.
When you build subversion, are you specifying the same openssl libraries used to build apache, or some other ones? (I don't remember if recent svn versions include a deps zip file, but those dependencies are usually out of date, and in this case are probably including openssl 0.9.8 ).
You are right it was compiled against 0.9.8q.
However building against OpenSSL 1.0.0c make trouble creating libsvn_ra.dll due a incompability in neon. I gonna try the newest version from neon if that works.
I made a test update for 32 bit. Let me know if that works for you
dev.mariobrandt.de/mod_svn-1.6.15-x86r2.zip
---- edit ----
Note: doesn't compile with IPv6 apache :-/ But it runs with it ;-)
Quote from: mario on December 18, 2010, 09:35:09 PM
I made a test update for 32 bit. Let me know if that works for you
dev.mariobrandt.de/mod_svn-1.6.15-x86r2.zip
---- edit ----
Note: doesn't compile with IPv6 apache :-/ But it runs with it ;-)
Yes, that makes svn.exe work with the apache ssleay32.dll.
(I suspect it doesn't affect the mod_dav_svn.so much if any, since it was already working and it doesn't use neon for network access.)
I would be be pleased if you could also test the x64 build
dev.mariobrandt.de/mod_svn-1.6.15-x64r2.zip
I added the second release from mod subversion to the download page. Updated to OpenSSL 1.0.0c and neon 0.29.5
Quote from: mario on December 20, 2010, 02:23:21 PM
I would be be pleased if you could also test the x64 build
dev.mariobrandt.de/mod_svn-1.6.15-x64r2.zip
64-bit version appears to work great!
Thanks!
Is WIN64 defined (and not just _WIN64) when building APR?
For reference, here is some discussion from the Subversion developers list:
http://svn.haxx.se/dev/archive-2011-02/0816.shtml
http://svn.haxx.se/dev/archive-2011-03/0096.shtml
Not sure if this would only affect the recently released 1.6.16 or not.
http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=260&expandFolder=74
need both WIN64 & _WIN64 ... seems to be both in APR IIRC ... but _WIN64 should be defined by the compiler .. mine does it I think ... need to check that tho
You can find the new version of mod_svn on the download page. Please report any issues.
Quote from: mario on March 08, 2011, 11:40:32 AM
You can find the new version of mod_svn on the download page. Please report any issues.
Is this built against the newer openssl libraries included with apache like r2 of 1.6.15? (The subversion deps usually contains an older version.)
I get an SSL library mismatch error when attempting to run the included executables using the https protocol:
I:\>svn ls https://server/sandbox
svn: OPTIONS of 'https://server/sandbox': SSL handshake failed: SSL disabled due to library version mismatch (https://server)
Quote from: kmradke on March 08, 2011, 06:25:44 PM
Is this built against the newer openssl libraries included with apache like r2 of 1.6.15? (The subversion deps usually contains an older version.)
I get an SSL library mismatch error when attempting to run the included executables using the https protocol:
I:\>svn ls https://server/sandbox
svn: OPTIONS of 'https://server/sandbox': SSL handshake failed: SSL disabled due to library version mismatch (https://server)
I think this is my problem. I tried to run the downloaded executables before I copied them to the httpd directory so they were missing ssleay32.dll and libeay32.dll from the apache install. Once I copied these, I was able to connect via https://. Sorry about the noise...
it is compiled against 1.0.0c
Is there any way to get notified when you guys release a new 64-bit svn module build (1.6.17 was released recently.) I hate to just keep asking or repeatedly checking the download page...
Sorry for the delay. I'm on it. On the weekend we had some holidays (From Thursday to Sunday.) First build failed. Than I noticed that the tag in svn was not identical to the tarballs.
I give it another shot to morror evening. Thanks for your patience.
I have some issues with the zlib component. See the errors from the build log. http://pastebin.com/eDLESGGr (x64 build)
I took zlib-1.2.5, updated sqlite-amalgamation to 3070603, updated neon to 0.29.6
Whole build log http://pastebin.com/byeTyR4R
I have the excat same errors while building the x86 version.
Looks like it's in need of expat
I hate how VC now can build more than one thing at a time, makes for a nearly impossible read of the log. I set mine to 1 thing at a time, doesn't slow the build down any.
Looking again I now see the zlib errors, are you sure it is finding what it is in need of, check your /LIBPATH stuff in the link part. Check that it is wanting the right filenames as well. OT example, mod_lua wants lua51.lib where mod_security wants lua5.1.lib .. same file... different filenames.
I'd say that with zlib it's the same problem I had when I tried it for the first time. I did quick test with my non-standard environment (so I can't confirm the whole build process), but for zlib the following seems to do the trick:
Open generated build\win32\build_zlib.bat and insert at line 51 (before "set BUILD_OPTS=..." line):
For x64:
set ASM_OPTS=AS=ml64 LOC="-DASMV -DASMINF -I." OBJA="inffasx64.obj gvmat64.obj inffas8664.obj"
For x86:
set ASM_OPTS=LOC="-DASMV -DASMINF -I." OBJA="inffas32.obj match686.obj"
That's wired! I guess I made it like
nmake -f win32/Makefile.msc AS=ml64 LOC="-DASMV -DASMINF -I." OBJA="inffasx64.obj gvmat64.obj inffas8664.obj"
But I'm not fully sure. I gonna try that tonight.
With x86 I'm sure I used
nmake -f win32/Makefile.msc OBJA=inffast.obj
so will have another try. Thanks for the hint!
Well my build still fails. But worse :D
========== Build: 9 succeeded, 18 failed, 7 up-to-date, 0 skipped ==========
Maybe I start over again with a fresh build.
Yes starting over and using zlib from the orig tar ball made the zlib errors go away. :o
@Sob Thanks for the hint!!!
There is an issue with neon left. ???
http://pastebin.com/8PnM86Tp
Those __imp__XML_* symbols are from Expat. Pointing the linker to libexpat.lib/libexpatw.lib (I'm not really sure which one) should help.
Then it leaves only _SSL_SESSION_cmp. It's from OpenSSL and it seems that it has been removed in 1.0.0. Quick research reveals that Neon can live with it (see lines 637-648 in ne_openssl.c). So it's probably just problem with defines, HAVE_SSL_SESSION_CMP and/or SSL_SESSION_cmp incorrectly defined somewhere?
HAVE_SSL_SESSION_CMP is nowhere defined in the source code.
SSL_SESSION_cmp is used / defined
openssl-1.0.0d\ssl\ssl_lib.c line arround 438,1498
openssl-1.0.0d\util\ssleay.num line 120
openssl-1.0.0d\doc\ssl\ssl.pod line 395
subversion-1.6.17\neon\src\ne_openssl.c line 678
I wanted to try it myself, this time the proper way, full build with everything as you do. Can't say it went too well.
First there was problem with Apache 2.2.19. Release/x64 config had more than half of subprojects (modules, etc..) set to Win32 (x86), so they didn't build. I didn't find an easy way to add x64 target only where it was missing, so I had to remove x64 completely and then recreate it from Win32. Apache then built fine, but it messed up output paths (added x64 subdirectory). But ok..
With SubVersion I added all required dependencies, but then I still hit the exactly same problem as before, missing svn's own symbols everywhere. Dlls (libsvn*.dll) compiled just fine, but the symbols required by exes and Apache modules were not in libsvn*.lib where I'd expect them, but only in svn*.lib. And linking to them produces static executables and modules that don't need svn dlls. I have no idea what I've done wrong. Maybe it's somehow related to Apache build problems, gen-make.py looking for something it couldn't find and creating incomplete project files? But it didn't complain about anything.
I had no missing _SSL_SESSION_cmp in libsvn_ra_dll project, but since it all went differently than your build, I'm not sure that it says anything useful.
The only idea I have for you is to try removing the conditions around Neon-defined SSL_SESSION_cmp, to be sure that it's always defined.
Sob,
cvtdsp64.bat
@rem = '--*-Perl-*--
@echo off
if "%OS%" == "Windows_NT" goto WinNT
perl -x -S "%0" %1 %2 %3 %4 %5 %6 %7 %8 %9
goto endofperl
:WinNT
perl -x -S %0 %*
if NOT "%COMSPEC%" == "%SystemRoot%\system32\cmd.exe" goto endofperl
if %errorlevel% == 9009 echo You do not have Perl in your PATH.
if errorlevel 1 goto script_failed_so_exit_with_non_zero_val 2>nul
goto endofperl
@rem ';
#!C:\usr\bin\perl.EXE -w
#line 15
##################################################################
# Script Name: Convert Apache DSP files to x64
# FileName: cvtdsp64.pl
# Date: November 18, 2010
#
# revision 2010-1212-1552 [Version 1.0]
#
##################################################################
my $osh = ".\\os\\win32\\os.h";
my @LISTDSP = ('DIR','/B','/S','*.DSP','>','DSPS.list');
my @MODSMK = ('DIR','/B','/S','modules.mk.win','>>','DSPS.list');
system(@LISTDSP);
system(@MODSMK);
my @dsps = read_file('./DSPS.list');
my @OSH = read_file($osh);
foreach (@dsps) {
my @dspcontents = read_file($_);
print "Converting ".$_."\n";
$prepped = join("\n",@dspcontents);
my $pcre = "TRUE" if $_ =~ /srclib\\pcre/i && $prepped =~ /\/x64/;
if ($prepped =~ /machine:(X86|I386)/i) {
$prepped =~ s/machine:(X86|I386)/machine:X64/gi; # for it exists, change it
}
else {
if ($_ =~ /(support|httpd\.dsp)/i && $prepped !~ /machine:X64/i) {
$prepped =~ s/subsystem:console/subsystem:console \/machine:X64/gi; # add for dll & so w/ opt:ref
}
if ($_ =~ /(libhttpd|ApacheMonitor)\.dsp/i && $prepped !~ /machine:X64/i) {
$prepped =~ s/subsystem:windows/subsystem:windows \/machine:X64/gi; # add for dll & so w/ opt:ref
}
$prepped=~ s/\/debug \/out:/\/debug \/machine:X64 \/out:/gi;
}
$prepped=~ s/baseaddr\.ref/baseaddr64\.ref/gi; # for x64 baseaddr
$prepped=~ s/\/mktyplib203 \/win32/\/mktyplib203 \/x64/gi; # for x64 midl
$prepped=~ s/\/mktyplib203 \/o \/win32/\/mktyplib203 \/o \/x64/gi; # for x64 midl
$prepped=~s/\/D "WIN32"/\/D "WIN32" \/D "WIN64"/gi; # unlock x64 specific code
$prepped=~s/\/MACHINE:(X86|I386)/\/machine:X64/gi; # catch any /machine that slid by
$prepped=~s/x64\\Debug/Debug/gi; # for putting x64 dlls in x86 locations Debug
$prepped=~s/x64\\Release/Release/gi; # for putting x64 dlls in x86 locations Release
$prepped=~s/x64\\LibD/LibD/gi; #for putting x64 libs in x86 locations LibR
$prepped=~s/x64\\LibR/LibR/gi; #for putting x64 libs in x86 locations LibR
$prepped=~ s/LIB32 \/nologo \/out:/LIB32 \/nologo \/machine:X64 \/out:/g; # for static libs
unless ($_ =~ /srclib\\apr/i || $pcre) {
#
# Already have x64 targets in APR and the pcre projects for Apache 2.3 AH,
# so do not modify the Win32 targets in APR
#
$prepped=~ s/Win32 Release/x64 Release/gi ; # convert Win32 Release targets to x64
$prepped=~ s/Win32 Debug/x64 Debug/gi ; # convert Win32 Debug targets to x64
}
skipit:
open(WRI,">".$_) || die ("Can't open $_ for output");
print WRI $prepped."\n";
close(WRI);
}
$oshprep = join("\n",@OSH);
unless ($oshprep =~ /\#define PLATFORM "Win64"/) {
$oshprep =~ s/^\#define PLATFORM "Win32"/\#define PLATFORM "Win64"\n\#define WIN64/g;
open(WRI,">".$osh) || die ("Can't open $osh for output");
print WRI $oshprep."\n";
close(WRI);
}
my @CLEANUP = ('DEL','/F','/Q','DSPS.list');
system(@CLEANUP);
exit 0;
# END main()
# Read File ######################################################
sub read_file {
(my $read_file)=@_;
my @filecontents;
$read_file=~s/\n//;
if (-e "$read_file") {
open(READ,"$read_file") || return ("Can't Open File: $read_file\n");
@filecontents = <READ>;
close(READ);
}
else {
return ("Cannot find file: $read_file\n");
}
chomp @filecontents;
return @filecontents;
} # End sub read_file
##################################################################
# End cvtdsp64.bat #
__END__
:endofperl
@rem ';
Here my short way it worked to compile subversion /until now ;)
Get
http://subversion.tigris.org/downloads/subversion-1.6.17.zip and http://subversion.tigris.org/downloads/subversion-deps-1.6.17.zip
C:\python27\python gen-make.py -t vcproj --vsnet-version=2008 --with-httpd=C:\build\httpd-2.2.19-sni6-x64
--with-openssl=C:\build\httpd-2.2.19-sni6-x64\srclib\openssl
--with-zlib=C:\build\subversion-1.6.17-x64\zlib --with-apr=C:\build\subversion-1.6.17-x64\apr
Open generated build\win32\build_zlib.bat and insert at line 51 (before "set BUILD_OPTS=..." line):
set ASM_OPTS=AS=ml64 LOC="-DASMV -DASMINF -I." OBJA="inffasx64.obj gvmat64.obj inffas8664.obj"
OPEN IDE
x86
C:\python27\python gen-make.py -t vcproj --vsnet-version=2008 --with-httpd=C:\build\httpd-2.2.19-sni6-x86
--with-openssl=C:\build\httpd-2.2.19-sni6-x86\srclib\openssl
--with-zlib=C:\build\subversion-1.6.17-x86\zlib --with-apr=C:\build\subversion-1.6.17-x86\apr
Open generated build\win32\build_zlib.bat and insert at line 51 (before "set BUILD_OPTS=..." line):
set ASM_OPTS=LOC="-DASMV -DASMINF -I." OBJA="inffas32.obj match686.obj"
OPEN IDE
Ok, I tried it again:
- cvtdsp64.bat helped, but the resulting project files had problems when compiling resources (rc.exe call)
- srclib\apr\build\cvtdsp.pl -2005 fixed that
- there were complaints (errors) about missing BaseAddr64.ref
- not sure about it, I copied it from BaseAddr.ref and it changed errors to warnings
- good enough for Apache to compile ;)
- with SubVersion my original linking problem was caused by Python not in PATH; I only had .py associated, but build process calls it directly and I overlooked that before
- neon 0.28.3 from deps does not have workaround for SSL_SESSION_cmp removed from OpenSSL, so it fails with unresolved symbol
- neon 0.29.6 has the workaround (own function) and problem is gone
- missing Expat symbols (__imp__XML_*) remain
- I first thought about linking to external Expat (if it wants it, just let it have it), but something felt wrong about it; if problem was only with linking, it must have got the headers from somewhere and .lib should be from the same source
- that source is httpd\srclib\apr-util\xml\expat\lib and lib is xml.lib, everything seemed to be prepared, yet it didn't work
- the missing symbols had extra "__imp__" prefixed and it came from #define XMLIMPORT __declspec(dllimport) in httpd\srclib\apr-util\xml\expat\lib\expat.h and it was conditional
- jump right to the end, the magic solution is to add "/D XML_STATIC" to EXPAT_FLAGS in neon\neon.mak, line 57
- build ok :)
well .. perl srclib\apr\build\ctvdsp.pl -2005 still needs to be done .. after the x64 convert .. should of mentioned it ... for me it is automatic .. I don't even think about it when building .. my body is trained to just do without thinking .. which sometimes gets me in trouble ;)
And what about that missing BaseAddr64.ref? Original source has BaseAddr.ref and the file exists. Running cvtdsp64.bat changes dependencies to BaseAddr64.ref, but does not provide the file in any way.
Building of many components then ends up with:
LINK : fatal error LNK1104: cannot open file 'os\win32\baseaddr64.ref'
After providing own BaseAddr64.ref, either the copy of BaseAddr.ref or just empty file, the result is:
os\win32\baseaddr64.ref : warning LNK4198: base key 'libhttpd.dll /opt:ref' not found - using default
I asked Google, but got only three results for BaseAddr64.ref, all from this thread. Not very helpful. ;D
Yes, it's not perfect, and you get that. I am going to just remove the /base@ altogether. It's on my list of todo's. just /opt:ref should be fine.
Those are hardcoded in apr, I was thinking of giving it an attempt again. There is a magic number that needs to be added to the addresses in the 32 bit one to be inline with x64. I cannot remember but have it written down somewhere.
upgrading neon and adding "/D XML_STATIC made it, but now there is a new error >:(
13>------ Build started: Project: libsvn_ra_neon, Configuration: Release Win32 ------
13>Compiling...
13>commit.c
12>zlibstat.lib(inflate.obj) : error LNK2019: unresolved external symbol _inflate_fast referenced in function _inflate
12>..\..\..\Release\subversion\libsvn_subr\libsvn_subr-1.dll : fatal error LNK1120: 1 unresolved externals
12>Build log was saved at "file://c:\build\subversion-1.6.17-x86\Release\subversion\libsvn_subr\BuildLog.htm"
12>libsvn_subr_dll - 2 error(s), 2 warning(s)
14>------ Build started: Project: libsvn_delta_dll, Configuration: Release Win32 ------
14>Performing Custom Build Step
14>Compiling...
14>empty.c
13>util.c
14>Compiling resources...
14>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
14>Copyright (C) Microsoft Corporation. All rights reserved.
14>Linking...
14> Creating library ..\..\..\Release\subversion\libsvn_delta\libsvn_delta-1.lib and object ..\..\..\Release\subversion\libsvn_delta\libsvn_delta-1.exp
13>session.c
14>zlibstat.lib(inflate.obj) : error LNK2019: unresolved external symbol _inflate_fast referenced in function _inflate
14>..\..\..\Release\subversion\libsvn_delta\libsvn_delta-1.dll : fatal error LNK1120: 1 unresolved externals
14>Build log was saved at "file://c:\build\subversion-1.6.17-x86\Release\subversion\libsvn_delta\BuildLog.htm"
14>libsvn_delta_dll - 2 error(s), 0 warning(s)
13>replay.c
13>props.c
21>------ Build started: Project: libsvn_ra_dll, Configuration: Release Win32 ------
20>wc_db.c
21>Performing Custom Build Step
21>Compiling...
21>empty.c
21>Compiling resources...
21>Microsoft (R) Windows (R) Resource Compiler Version 6.1.6723.1
21>Copyright (C) Microsoft Corporation. All rights reserved.
21>Linking...
20>util.c
21> Creating library ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.lib and object ..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.exp
21>libneon.lib(inflate.obj) : error LNK2019: unresolved external symbol _inflate_fast referenced in function _inflate
21>..\..\..\Release\subversion\libsvn_ra\libsvn_ra-1.dll : fatal error LNK1120: 1 unresolved externals
21>Build log was saved at "file://c:\build\subversion-1.6.17-x86\Release\subversion\libsvn_ra\BuildLog.htm"
21>libsvn_ra_dll - 2 error(s), 0 warning(s)
20>update_editor.c
Well now I'm confused! the x64 build is ok! Gonna upload it tomorrow and do the release. I wonder why the x86 build still fails. Too tired to figure out anything now ;)
It's not a new error, it's our old troublemaker _inflate_fast from zlib. Maybe you forgot to change build_zlib.bat (https://forum.apachehaus.com/index.php?topic=143.msg936#msg936) for x86 build? I got the same errors without it, but it went away with the modification.
Done! Downloads will be very soon on the download page!
The new 1.7 RC 3 can be found on the download page. It is recomment NOT to use in this in productive systems, only for testing
Can someone please test [LINK removed]
I get the error 0xc000007b when running. Even when the build is without any issues. So I think it is an issue with the build system to run it.
with 1.6.15r2 kmradke told it works fine, but that also fails for me with the same issue.
Quote from: kmradke on December 21, 2010, 05:51:37 AM
64-bit version appears to work great!
Thanks!
Thanks a lot for testing
I was able to test it myself in virtualbox. Works fine :)