Table of Contents

Apache HTTPD 2.4.9 seemed to be needed to compile apache httpd natively on 64 bit Windows 7.

The following are notes on compiling up the dependencies for Apache httpd 2.4.9, but haven't got Apache Httpd 2.4.9 itself compiling on it yet. But the existing GS2 apache httpd 2.2.x does compile still on 64 bit, for which it needs the Visual Studio environment to be set to 32 bit.

Trying to get httpd-2.4.9 to compile on 64 bit Windows 7

1 Download the cmake binary from:

2 Download the pcre source code from: http://www.pcre.org/ (ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/)

3. Building PCRE on windows: Relevant instructions for this are in

file:///C:/Users/Me/httpd-2.4.9/srclib/pcre-8.35/NON-AUTOTOOLS-BUILD

section "BUILDING PCRE ON WINDOWS WITH CMAKE"

4. After installing CMake, put cmake\bin on path:

C:\Program Files (x86)\CMake 2.8\bin

5. Unzip pcre-8.35 into httpd\srclib and make sure to rename it to as "pcre", since that's what apache-httpd's makefile expects.

They advise that there should preferrably be no spaces in the file path to pcre:

C:\Users\Me\httpd-2.4.9\srclib\pcre

6. Create a build subfolder in pcre

C:\Users\Me\httpd-2.4.9\srclib\pcre\build

7. In our case, the cmake-gui needs to be run from a DOS prompt that is set up for Visual Studio.

Run the Visual Studio 2008 x64 Win64 Command Prompt from the Windows Start Menu. The DOS prompt that appears is now set with Vis Studio 9.0 (VS 2008)

8. Type "cmake-gui"

9. Paste into the first 2 fields of the CMake dialog:

C:/Users/Me/httpd-2.4.9/srclib/pcre
C:/Users/Me/httpd-2.4.9/srclib/pcre/build

10. Hit Configure and scroll down to choose "NMake Makefiles", and leave Use default native compilers selected

(If you wanted Vis Studio project files instead, you would have hit Configure and scrolled down to choose "Visual Studio 9 2008 Win64")

11. In the list of configure option flags it has generated, to get apache-httpd to compile with pcre"

12. Press Configure again, then press Generate

This will generate the makefiles that work with the nmake command from a DOS prompt.

13. Click Windows Start, rightclick on "Visual Studio 2008 x64 Win64 Command Prompt" and choose "Run as Administrator"

cd to C:\Users\Me\httpd-2.4.9\srclib\pcre\build
nmake /f Makefile
nmake /f Makefile install

It is the install step that requires the VisStudio DOS prompt being in admin mode.

14. Finally, now that all the dependencies for apache httpd have been set up, it's time to start trying to compile apache httpd 2.4.9 itself:

cd to C:\Users\Me\httpd-2.4.9
nmake /f Makefile.win

15. Error:

	C:\Users\Me\httpd-2.4.9>nmake /f Makefile.win

	Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
	Copyright (C) Microsoft Corporation.  All rights reserved.


	INSTDIR     = \Apache24
	DOMAINNAME  = example.com
	SERVERNAME  = www.example.com
	SERVERADMIN = [email protected]
	PORT        = 80

	To change these options use 'nmake -f Makefile.win [option=value]'
	Example: nmake -f Makefile.win PORT=8080


	Building Win32 Release targets (R suffixes)
	'msdev' is not recognized as an internal or external command,
	operable program or batch file.
	NMAKE : fatal error U1077: 'msdev' : return code '0x1'
	Stop.
	NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0
	\VC\BIN\amd64\nmake.exe"' : return code '0x2'
	Stop.

Trying to track down the occurrences of msdev points to several makefiles in httpd-2.4.9

C:\Users\Me\httpd-2.4.9>findstr /s /M /C:"msdev" *.*

According to http://www.apachelounge.com/viewtopic.php?t=4671, it appears that the msdev command was used in earlier versions of VisStudio and that it had been replaced by the devenv command:

	PostPosted: Wed 11 Apr '12 19:02    Post subject: 	Reply with quote
	I'll assume by the error this is Visual Studio Express but first, yes you compile APR, APR-Util & APR-Iconv while compiling httpd just like in 2.2.x. PCRE is no longer included and has to be downloaded and compiled separately.

	It's odd that VC 9/10 Express triggers msdev (vc6) and not devenv (vc7 & up). It doesn't really matter since you do not have either.

	With the express version, right click on the BuildBin project, select Project Dependencies and in the dialog that comes up select/check;
	apr_dbd_odbc

	If you have zlib compiled and in the srclib folder;
	mod_deflate

	if you have OpenSSL compiled and in srclib folder;
	abs
	mod_ssl

	if you have LUA compiled and in srclib folder;
	mod_lua

	If you have libxml2 compiled and in srclib folder;
	mod_proxy_html
	mod_xml2enc


	You will still see those msdev errors at the end of the build but all these modules and the odbc connector will already be built so there should be no problem come time you install to disk (Installbin).

I haven't tried this proposed solution yet, as I managed to get the original apache-httpd (2.2.x) that we include with GS2 to compile on Win 7 64 bit after all, by setting the environment to 32 bit mode, using the setup32.bat at http://trac.greenstone.org/browser/local/greenstone2/windows-64bit/setup32.bat

Compiling the apache-httpd included with GS2 on 64 bit Windows 7

The compilation environment needs to be set to 32 bit mode. For this, use the environment setup script at http://trac.greenstone.org/browser/local/greenstone2/windows-64bit/setup32.bat

Checkout http://trac.greenstone.org/browser/local/greenstone2/windows-64bit into Greenstone 2 as a folder called local and rename setup32.bat to setup.bat. One-off steps:

(open a fresh DOS prompt, with no environment settings)
cd GS2
svn co http://svn.greenstone.org/local/greenstone2/windows-64bit local
cd local
move setup.bat setup64.bat
move setup32.bat setup.bat
cd ..

Now, whenever you need to compile this GS2, run the usual toplevel GS2 setup.bat script, which will run local/setup.bat (the 32 bit version). Then it is ready to compile and you can call makegs2x64.bat

setup.bat
makegs2x64.bat

Notes on if compilation fails:

In the same DOS prompt, recompile with nmake /f win32.mak APACHE_HTTPD=1. Throw in DEBUG=1 if you had initially compiled with the debug option. If it fails again, repeat.

Compiling for debugging, which is Option 5 of the makegs2x64 menu (which will compile apache too and turn debugging on) doesn't need MS SDK anymore. But it may fail compilation the first time, either with an error about some "if" statement in a win32.mak file or else with an error about it being unable to create a "tempfile.bat".

Dr Bainbridge explained that this was due to a race condition on multi core systems, which Sam had noticed. The tempfile.bat is sometimes created too late by another core to be able to be used by another. Dr Bainbridge said that there were some flags passed throughout either apache or the GS source code to control this, although the changes don't seem to be on SVN in the apache folder.

In that case, run makegs2x64.bat again, choosing Y to re-unpack zip files and then choosing Option 6 to make Clean. Then recompile with the debugging on again, Option 5, and it compiles to completion and gs2-server.bat works and runs the apache server.

Alternatively, no need for make clean or unpacking zip files again. Just a new DOS prompt with the local\setup.bat setting up the VS environment again as before. Then run makegs2x64.bat again, choosing Option 5 and everything compiles up successfully.

IMPORTANT NOTE: Sam's fix was committed to the release kit. See changeset 22490.

Using VS 12 or 10 instead of VS9

Using Visual Studio 12 or 10 in 32-bit mode in place of VS9.0 may work on other 64 bit Win 7 machines, but there is some issue with the VS 12 toolset which results in link errors.

When trying to compile with VS12 in a 32 bit env on the 64 bit Win 7 machine, the errors start with something like

error LNK2019: unresolved external symbol __InterlockedIncrement referenced

See https://groups.google.com/forum/#!topic/UniMRCP/Iybpn51UYnI

The suggested solutions mentioned at the links MSDN, can-i-set-the-platform-toolset-from-the-command-line-when-building-with-vs2010s is to use the /p:PlatformToolset=v100 flag to resort to the VS 10 toolset when compiling. (Further links are also in the earlier revision of the setup32.bat script.)

However, on our Win 7 machine, currently the Visual Studio 10 is incomplete as it's missing its toolset, so it can't be used either. That's why we're using VS 9.