Keep Server Online
If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.
or
A donation makes a contribution towards the costs, the time and effort that's going in this site and building.
Thank You! Steffen
Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
| |
|
 Topic: Building on Windows, mod_http2 with nghttp2 |
|
| Author |
|
deltamind106
Joined: 22 Aug 2012
Posts: 9
Location: Boston, USA
|
 Posted: Wed 30 Aug '17 22:14 Post subject: Building on Windows, mod_http2 with nghttp2 |
 |
|
So I've gone through the extremely painful process of building the Apache httpd source tree distribution on Windows using Visual Studio. This includes all the optional modules that come bundled with the httpd source, such as mod_http2.
The question comes up, in order for mod_http2 to work correctly with SSL, do I need to build nghttp2 (the external 3rd party library required to buidl mod_http2) with OpenSSL?
Initially I built nghttp2 without it having any knowledge of OpenSSL, libxml2, and zlib. But if I want mod_http2 to work with SSL, compression, etc., then maybe I need nghttp2 to be built with these options enabled?
I guess my question is, when Apache Lounge does its build of nghttp2 and mod_http2, do you build nghttp2 with openssl, libxml2, and zlib enabled? |
|
| Back to top |
|
glsmith
Moderator
Joined: 16 Oct 2007
Posts: 2268
Location: Sun Diego, USA
|
| Posted: Thu 31 Aug '17 3:55 Post subject: Re: Building on Windows, mod_http2 with nghttp2 |
|
|
| deltamind106 wrote: |
I guess my question is, when Apache Lounge does its build of nghttp2 and mod_http2, do you build nghttp2 with openssl, libxml2, and zlib enabled? |
Simple answer, no, no and no.
nghttp2 is just the library that does the heavy lifting for the protocol. It doesn't care about tls, the browser vendors are forcing this because they want https everywhere. h2c is http2 for non-tls connections (curl will do them).
It doesn't care about xml or compression either. The nghttp2 client probably wants these but not the library itself.
P.S. A couple more times and I doubt you will think it painful any longer. |
|
| Back to top |
|
deltamind106
Joined: 22 Aug 2012
Posts: 9
Location: Boston, USA
|
| Posted: Fri 01 Sep '17 15:46 Post subject: Re: Building on Windows, mod_http2 with nghttp2 |
|
|
| glsmith wrote: |
Simple answer, no, no and no. |
Awesome... I figured that was 'probably' the case, and thanks so much for the quick answer!
| glsmith wrote: |
P.S. A couple more times and I doubt you will think it painful any longer. |
Not only will it not be painful the 2nd time around, it will be downright easy by comparison. I'm astounded at how many little things one must tweak to get it to build. Obviously some of the difficulty comes from the inevitable drift of the multiple disjoint projects that must come together. But other problems should be just plain fixed in the sources so builders don't have the hassle.
Some of my personal favorites:
1. The use of /Yciconv.h and /Yuiconv.h in apr-iconv. This would be awesomely hilarious if it didn't stop every last builder in his tracks with an incomprehensible error that's essentially impossible to track down unless you're a windows guru.
2. The fact that the Lua library from lua.org doesn't have any kind of windows makefile. I mean, how hard can it be for them to include this? I created one in about 5 minutes.
3. The apache ".dsp" files don't have CR-LF line termination, and therefore fail to import into Visual Studio. So you don't need *all* the files to be CR-LF, just the .dsp files. If they made just those files CR-LF, then nonsense like the lineends.pl script could go away.
4. The apache makefile always wants to copy .pdb files into the installation folder, and then fails when they don't exist. So when libapr-1.pdb is obviously not found, the whole installer fails, requiring you to to tweak it.
These were my personal favorites, although there were about 20 different tweaks I documented to get it all to work. |
|
| Back to top |
|
glsmith
Moderator
Joined: 16 Oct 2007
Posts: 2268
Location: Sun Diego, USA
|
| Posted: Fri 01 Sep '17 19:37 Post subject: |
|
|
I hear your pain.
1. Beginning with some VC version the precompiled headers fail. Works fine on prior versions. VC9, 10 & 11 are still non-EOL. That said, a new release of apr-iconv with those removed is unlikely, but anything is possible.
2. I agree, how hard is it to just copy 5.1's and modify it, then again, I don't think it needs any modification. If it does it's not much.
3. Your fault. There are win32 downloads (.zip) that have the crlf line endings. OK not your fault since I see none for 2.4.27. .tar.gz is for Unixish builds. There is a note about building from these in the Windows compiling doc. Run:
C:\httpd-2.4.x> perl srclib\apr\build\lineends.pl
4. Using VC10? It's got a major bug in ignoring /implib:libapr-1.lib (you get libapr.lib) during conversion so it seems possible that it ignores /pdb:libapr-1.pdb (get libapr.pdb maybe) as well (don't know, don't care to install it to find out), otherwise works for me as I get the pdb on vc6, 9, 11, 12, 14 & 15. http://sk.uploads.im/WmBYy.png
Apart from the various dependencies that ASF has no control over, building apache at the command line on VC10+ is a breeze and rarely fails.
Every new version of VC seems to have it's own quirk along with the quirks from the versions below. Nothing remains consistent, if it did, it would be easy to handle the setargv() problem in the dsp & mak files for Apachemonitor with the environment variable VCINSTALLDIR, but they can't even keep that consistent, some have a trailing \, some don't. ARGH! Go back far enough and it MSVCHOME. |
|
| Back to top |
|
deltamind106
Joined: 22 Aug 2012
Posts: 9
Location: Boston, USA
|
| Posted: Tue 05 Sep '17 16:39 Post subject: |
|
|
I'm using VC14. But I was building from the IDE. One might ask why in the world would I do that, rather than just use the command line (which I much prefer). Well, according to the Apache web page for building on windows:
| Quote: | | Note only the .dsp files are maintained between release builds. The .mak files are NOT regenerated, due to the tremendous waste of reviewer's time. Therefore, you cannot rely on the NMAKE commands to build ... |
It seems like the above statement is maybe not true any more. If so, then maybe they could consider updating the web page, so every builder doesn't immediately go down a rabbit hole that's way off the beaten path?
So is it the .dsp or the .mak files, that are the official-Apache-Windows-build-system-of-record(tm)? |
|
| Back to top |
|
|
|
|
|
|
