Topic: Building Apache 2.4.12 Windows x64 with cmake

[wangmaster]

Disclaimer: Windows build newbie here. I'm a straight up unix guy.

I'm trying to build a 64-bit Apache 2.4.12 with zlib, openssl, pcre, apr, and apr-util.

I honestly have no idea what I'm doing. I'd like to build a single deployable bundle (similar too the way the visual studio projects for apache builds) so I've done the following:
1) compiled openssl using make. changed:
INSTALLTOP
OPENSSLDIR
to C:/Apache24 to install the openssl files into C:/Apache24
2) used cmake and nmake to build pcre and installed to C:/Apache24
3) compiled zlib using nmake. However, zlib has no install target so I have no idea how to install it. Looking at the previous projects I was thinking I could manually copy the lib, dll/pdb and h files to the various directories under C:/Apache24 - skipped this for now though.
4) used cmake and nmake to build apr and installed to C:/Apache24
5) trying to use cmake to configure apr-util. I've set APR_INCLUDE_DIR and APR_LIBRARIES to point to the C:/Apache24 location, but cmake still complains:

[Jan-E]

Below the Apache build directory there should be a subdir srclib with subdirectories: apr, apr-iconv, apr-util, openssl, pcre and zlib.

Openssl should be compiled, with filled subdirs openssl\out32 and openssl\out32dll.

That is the way it works with the makefiles. Maybe CMake uses the same directory tree.

FWIW: CMake happens to be quite clever at finding openssl: it once found my Openssl in \OpenSSL\Win32\1_0_1i. If the directory tree below srcdir does not work, just put openssl in C:\openssl. Probably CMake will find it there.

For a Windows newbie: Win7+ is capable of making directory symlinks. I always put the wanted version of opensll below srclib with a batch file containing

cd srclib
rd openssl
mklink /D openssl \openssl\opensslvc11.x64

This way I can easily switch from building for x86 and x64 without recompiling open ssl every time.

[wangmaster]

The README.cmake documentation is pretty clear that cmake doesn't use the srclib mechanism but instead relies on the dependencies needing to be built and installed.

The problem with your idea of putting openssl somewhere else is I'd really need to build a self-contained redistributable apache, including all the dependencies. Kind of like how the current visual studio build process does it. Having to build openssl into another location defeats that purpose. One possibility I had considered was installing it into some location that the cmake locator can find it in but then installing it into the apache directory again afterward but that seems silly and it seems like it should be unnecessary.

[Jan-E]

CMake needs the OpenSSL *.libs in openssl\out32dll to link apache to the ssl DLL's at compile time. You do not have to distribute the whole openssl source tree. That would be really silly. Just copy the necessary files after compiling in the apache\bin directory. The VC-builds tell you which files to use.

BTW: what is so special about you setup that you cannot use the Apachelounge downloads? It is perfectly possible to use those for your purpose, I think.

[wangmaster]

I'm not talking about distributing the entire openssl source tree. I'm talking about the built openssl tree (make install, libraries, openssl.exe, include files, etc).

Yes, I know that I can copy what I need manually, but what I'm looking for is a proper way of doing this. The documentation for the httpd cmake build is unfortunately not very clear, nor is it very thorough.

I can't use the apachelounge builds because this is our custom "fork" of httpd. We have numerous patches for our own purposes that don't make sense upstream and thus we maintain them ourselves.

I'll try the srclib trick. See if that works.

[wangmaster]

So I started thinking about how to do this, and I'm not sure how this would work.

The apache cmake build requires that the dependencies are built (apr, apr-util, openssl, zlib).

my problem is, I can build openssl, zlib and apr-util.

But how do I make apr-util see openssl?

Using srclib does not work. apr-util does not see openssl in srclib (which sort of makes sense, how would it as it's a separate build of it's own).

Just curious, but have you actually done this build?

[Jan-E]

[wangmaster]

[Jan-E]

Install https://slproweb.com/download/Win64OpenSSL-1_0_1L.exe from https://slproweb.com/products/Win32OpenSSL.html in the default directory and CMake will find it.

I just tried it out of curiosity and it found 0.9.8ze which I had also installed.

Whereever CMake finds OpenSSL, in the end it should install all needed files in the CMAKE_INSTALL_PREFIX directory. See the README.cmake of Apache.

[wangmaster]

[Jan-E]

If I were you I would skip CMake, because it apparently is causing a lot of trouble.
Did you try to use use Gregg's *.mak files and run

nmake -f Makefile.win PORT=80 INSTDIR="C:\Apache24" installr

Then you will be a lot closer to the solution than with CMake, I guess.

I took another road. I made a X86 VC11 project first and then added the x64 configuration to the Apache/httpd project. At first this seems to fail, because the builds are made in .\x64\Release and the like. I did a global find and removed every x64\ and \x64 in all *.vcxproj files.

The VC11 project itself fails because of missing lua.h and the like, but I call it from the command line:

[wangmaster]

Hehe. Funny you should ask that.
See:
http://www.apachelounge.com/viewtopic.php?t=6368

My goal here is to be able to create a reproducible build without the need to depend on "random" resources.

With 32-bit httpd I'm able to reproduce a build using nothing more than the source bundles from the various groups (httpd httpd-deps openssl pcre zlib).

I'm trying to avoid having to rely on on artifacts generated from someone else. At the very least, I'd like to learn how to generate those artifacts.

[Jan-E]

[wangmaster]

Thanks to Jeff Trawick on users@httpd.apache.org I have a successful build.

The issue with apr-util not finding openssl was that I was trying to use openssl 1.0.2 and it just simply doesn't work.

Dropped back to openssl 1.0.1l and so far so good.

[wangmaster]

My pet peeve is coming across forum postings and not seeing any detail in the final resolution to them So I'm not going to be that guy.

Here's how I built everything:
openssl:
perl Configure VC-WIN64A --prefix=$PREFIX
ms/do_win64a.bat
nmake -f ms/ntdll.mak
nmake -f ms/ntdll.mak test
nmake -f ms/ntdll.mak install

zlib:
cmake -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX=$PREFIX -DCMAKE_BUILD_TYPE=RelWithDebInfo -DAMD64=ON $ZLIB_SRCDIR
nmake
nmake test
nmake install

note: zlib with AMD64 on fails to link. This is currently not fixed as of 1.2.8. There is a fix in github:
https://github.com/madler/zlib/pull/72

pcre:
cmake -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX=$PREFIX -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_SHARED_LIBS=ON -DPCRE_BUILD_PCRECPP=OFF -DPCRE_BUILD_PCREGREP=OFF -DPCRE_SUPPORT_UTF=ON $PCRE_SRCDIR
nmake
nmake test
nmake install

apr:
cmake -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX=$PREFIX -DCMAKE_BUILD_TYPE=RelWithDebInfo -DAPR_INSTALL_PRIVATE_H=ON $APR_SRCDIR
nmake
nmake install

apr-util:
cmake -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX=$PREFIX -DOPENSSL_ROOT_DIR=$PREFIX -DAPU_HAVE_CRYPTO=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo $APRUTIL_SRCDIR
nmake
nmake install

httpd:
cmake -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX=$PREFIX -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_MODULES=i $HTTPD_SRCDIR
nmake
nmake install

$PREFIX is the same location

And yes, $PREFIX not %PREFIX%. My build script is a bash script

This is much much much more reproducible and automatable than the visual studio build process.

Couple of caveats:
I could not get apr to build the apr-1.pdb file with cmake 3.1.3

nmake test in pcre stack overflows with any version of cmake newer than 2.8.10.2. I didn't bother to figure out why as 2.8.10.2 works fine for me.

[Jan-E]

[idblew]

I've got this working with OpenSSL 1.0.2a and have written a HOW-TO which can be found at http://www.apachelounge.com/viewtopic.php?t=6462