Hello,
do you plan to release mod Subversion (mod_svn) VC14 binaries ?
Version 1.9.4 would be nice.
Thank you
Wolfgang
Hi Wolfgang,
the plan ist to build 1.9.4 on the weekend with VC11.
I haven't set up VC14 yet. So far I had no fun to install a second Windows installation on a different hard drive. Installing different VC versions parallel did not work in the past.
Is there a guide to compiling this for those of us requiring this for an upgrade? I've got a web server that requires mod_php and mod_svn. The majority of the content served is written in PHP and I'm looking to upgrade to PHP 7. At the moment, mod_php requires vc14 and mod_svn requires vc11. I attempted to work around this issue using mod_fcgid to run php externally, but have run into issues with scripts that need the ability to use PHP's set_time_limit function to extend processing time. The only solution is to either a) rewrite the affected scripts or b) use mod_php which necessitates mod_svn compiled with vc14.
Maybe you can setup a VM with Visual Studio 2015 installed on it to avoid conflicts?
I ran a simple test to see if apache VC14 could load the VC11 svn modules. From what I can tell it appears to work so this may be a non-issue for the time being.
I released VC11 subversion 1.9.4 binaries
Quote from: mario on May 04, 2016, 10:03:24 AMI haven't set up VC14 yet. So far I had no fun to install a second Windows installation on a different hard drive. Installing different VC versions parallel did not work in the past.
Shouldn't be a problem. I am running VC9, VC11 and VC14 (and VC8/10/13), x86 and x64 all on 1 machine. I have got 6 directories with dependencies:
C:\php-sdk\win32build.vc9
C:\php-sdk\win32build.vc11
C:\php-sdk\win32build.vc14
C:\php-sdk\win64build.vc9
C:\php-sdk\win64build.vc11
C:\php-sdk\win64build.vc14
When I open the VC14 x86 prompt I make a symlink in C:\php-sdk\win32build:
rd \php-sdk\win32build
mklink /J \php-sdk\win32build \php-sdk\win32build.vc14
So my dependencies are always in \php-sdk\win32build for x86 and in \php-sdk\win64build for x64. That is where the PHP build process is looking, but for compiling Apache this works equally well.
The parallel install worked! I'm doing the first test build now. So there might be VC14 builds soon'ish. I can't tell when exactly cause of limited time resources.
I still have some linking issue, but I will resolve that soon I think. Enough for today ;)
--- edit ---
------ Rebuild All started: Project: libsvn_ra_dll, Configuration: Release x64 ------
Generating libsvn_ra.def
Creating library C:\build\subversion-1.9.4-ap24-x64-vc14\Release\subversion\libsvn_ra\libsvn_ra-1.lib and object C:\build\subversion-1.9.4-ap24-x64-vc14\Release\subversion\libsvn_ra\libsvn_ra-1.exp
serf-1.lib(request_buckets.obj) : error LNK2001: unresolved external symbol __imp_sprintf
serf-1.lib(ssl_buckets.obj) : error LNK2001: unresolved external symbol __imp_printf
serf-1.lib(buckets.obj) : error LNK2001: unresolved external symbol __imp___iob_func
serf-1.lib(buckets.obj) : error LNK2001: unresolved external symbol __imp_fprintf
serf-1.lib(buckets.obj) : error LNK2001: unresolved external symbol __imp_vfprintf
C:\build\subversion-1.9.4-ap24-x64-vc14\Release\subversion\libsvn_ra\libsvn_ra-1.dll : fatal error LNK1120: 5 unresolved externals
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
Well serf isn't VC14 ready. There is some stuff done in trunk, but there wasn't a release yet. :-\
serf 1.3.8 can be compiled with the serf.mak for VC14. The errors you are getting are caused by linking a V11 binary with VC14.
Or do it the modern way with 'scons' for Windows:
Add '14.0' to the EnumVariable 'MSVC_VERSION' in SConstruct and run something like:
C:\build> scons APR=../apr APU=../apr-util ZLIB=../zlib OPENSSL=../openssl TARGET_ARCH=x64 PREFIX=.
I was using scons for VC11
python C:\Python27\scripts\scons.py APR=C:\build\httpd-2.4.16-x64\srclib\apr APU=C:\build\httpd-2.4.16-x64\srclib\apr-util OPENSSL=C:\build\httpd-2.4.16-x64\srclib\openssl ZLIB=C:\build\subversion-1.9.4-ap24-x64\zlib TARGET_ARCH=x64 MSVC_VERSION=11.0
BUT: there is no target MSVC_VERSION for VC14. Only in trunk.
if you tell me how to use the serf.mak ( make file), I'll use that. I don't prefer scons or VC command line as long as it works.
Quote from: mario on July 04, 2016, 02:55:34 PM
BUT: there is no target MSVC_VERSION for VC14. Only in trunk.
Just add it: line 138 of SConstruct
Quote from: mario on July 04, 2016, 02:55:34 PM
if you tell me how to use the serf.mak ( make file), I'll use that. I don't prefer scons or VC command line as long as it works.
I guess it is the serf.mak from previous branches that I was using:
https://svn.apache.org/repos/asf/serf/branches/1.2.x/serf.mak
But it may be no longer valid, so it is better to use scons anyway.
BTW
https://phpdev.toolsforresearch.com/mod_svn_vc14_x64.zip
https://phpdev.toolsforresearch.com/mod_svn_vc14_x86.zip
I started using Apache 2.4.23 x64 compiled with VC14 and tried installing the mod_svn links you provided here (mod_svn-1.9.4-ap24-x64.zip on Apache Haus Downloads and https://phpdev.toolsforresearch.com/mod_svn_vc14_x64.zip from post above), but both give me the error message:
Quotehttpd: Syntax error on line 107 of C:/Apache24/conf/httpd.conf: Cannot load modules/mod_dav_svn.so into server: The specified module could not be found.
Edit: I'm running it on Windows Server 2012 R2
mod_dav_svn.so depends on a lot of DLL's. My guess is that one of those 'cannot be found' (misleading message). Try putting all the DLL's in my mod_svn_vc14_x64.zip in Apache's bin-directory.
Thanks for helping Jan.
I copied all the dlls and other binaries from your mod in the /bin folder, so that wasn't the issue
It was a very indirect dependency, due to the way I compiled subversion (--with-berkeley-db). libsvn_fs-1.dll was in its turn dependent on libdb48.dll.
libdb48.dll wasn't in the zipfile. It now is:
https://phpdev.toolsforresearch.com/mod_svn_vc14_x64.zip
I downloaded Apache 2.4.23 x64 from here (Apachehaus), added the svn so's plus the DLL's and added 5 lines to the httpd.conf:
LoadModule dav_module modules/mod_dav.so
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule auth_digest_module modules/mod_auth_digest.so
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
bin\httpd -v
Server version: Apache/2.4.23 (Win64)
Server built: Jul 1 2016 10:38:22
bin\httpd -t -D DUMP_MODULES
Loaded Modules:
core_module (static)
win32_module (static)
mpm_winnt_module (static)
http_module (static)
so_module (static)
actions_module (shared)
alias_module (shared)
allowmethods_module (shared)
asis_module (shared)
auth_basic_module (shared)
authn_core_module (shared)
authn_file_module (shared)
authz_core_module (shared)
authz_groupfile_module (shared)
authz_host_module (shared)
authz_user_module (shared)
autoindex_module (shared)
cgi_module (shared)
dir_module (shared)
env_module (shared)
include_module (shared)
info_module (shared)
isapi_module (shared)
log_config_module (shared)
mime_module (shared)
negotiation_module (shared)
setenvif_module (shared)
socache_shmcb_module (shared)
ssl_module (shared)
status_module (shared)
dav_module (shared)
dav_fs_module (shared)
auth_digest_module (shared)
dav_svn_module (shared)
authz_svn_module (shared)
Yes, it worked for me. Thanks a lot for the update!
I recompiled SVN without berkeley db support:
https://phpdev.toolsforresearch.com/mod_svn_vc14_x64.zip
The one with bdb support is now here:
https://phpdev.toolsforresearch.com/mod_svn_bdb_vc14_x64.zip
No need to load the overhead of support of a database that no one still uses anyway.
Even better, thanks
Same change for the x86 version.
I recompiled SVN without berkeley db support:
https://phpdev.toolsforresearch.com/mod_svn_vc14_x86.zip
The one with bdb support is now here:
https://phpdev.toolsforresearch.com/mod_svn_bdb_vc14_x86.zip