While building Apache 2.0.48 with SSL the build fails just at the last moment while copying 'ssl-std.conf' to 'ssl.default.conf'. The file in the source is actually called '\httpd-2.0.48\docs\conf\ssl-std.conf.in' I was able to rename the file and a rebuild was successful. The source package was 'httpd-2.0.48-win32-src.zip'
[The above suggesting, produces a broken ssl.conf...unresolved @xxx@ values.] Same here, see... http://forums.devside.net/viewtopic.php?t=81 The .msi version, and most likely the .exe version, are also missing ssl.conf. Aside from myself, I have also confirmed this with 2 other people. The win32 Apache 2.0.48 build is (somewhat) broken. Here are my reposts... ---- copy docs\conf\ssl-std.conf "\Apache2\conf\ssl.default.conf" <.y The system cannot find the file specified. NMAKE : fatal error U1077: 'copy' : return code '0x1' Stop. NMAKE : fatal error U1077: '"E:\Program Files\Microsoft Visual Studio .NET\VC7 \BIN\nmake.exe"' : return code '0x2' Stop. ---- ssl-std.conf, that was present under httpd-2.0.47\docs\conf is no longer present under Apache 2.0.48, and is replaced with ssl-std.conf.in, which is not used under Makefile.win and is not processed (into ssl-std.conf) anywhere [that I can see] in the win32 distribution. ---- Basically, httpd-2.0.48\docs\conf\ssl-std.conf is missing from the distribution. This causes 3 files to never be created... ssl.default.conf ssl.conf dbmmanage.pl This happens because httpd-2.0.48\docs\conf\ssl-std.conf.in is never processed. (...forming ssl-std.conf) OR, this file was never ment to be processed under win32 and ssl-std.conf is just plain missing...As I can not find any mention of the extra @values@ used in ssl-std.conf.in anywhere in the distro. The good news is, this is the last step of the build/install process. The resulting Apache2 directory contains everything it should, except these 3 files. You can see this all at the very end of Makefile.win And this would explain why some people are claiming that their build finished! ... Looking at the source of 2.0.47, ssl-std.conf is present, while ssl-std.conf.in is not. The difference between 2.0.47 ssl-std.conf and 2.0.48 ssl-std.conf.in is that the later contains more layers of @values@ that need to be processed/resolved.
*** Bug 24546 has been marked as a duplicate of this bug. ***
Already resolved for .49 - please modify your Makefile.win to process the ssl-std.conf.in file rather than the ssl-std.conf source file.
When I said 'fixed' - I should add that I am working up a patch to deal with the newest substitution codes. That's a seperate matter/bug. Also note that the -win32-src.zip contains this single patch, already.
> please modify your Makefile.win to process the > ssl-std.conf.in file rather than the ssl-std.conf source file. Maybe I am confused, but under the unpatched .48 this would have the exact same effect as renaming ssl-std.conf.in to ssl-std.conf, and as a result, produce a broken ssl.conf > Also note that the -win32-src.zip contains this single patch, already. I have checked http://www.apache.org/dist/httpd/ and we still have the same old broken httpd-2.0.48-win32-src.zip , no extra code to process the @vars@ that are in ssl-std.conf.in, time-stamped 10/29 The solution that worked for myself, was to copy over ssl-std.conf from .47 over to .48 before the build
*** Bug 24937 has been marked as a duplicate of this bug. ***
Note that ssl-std.conf.in substitutions are still required to complete this solution. The source of ssl-std.conf.in instead of ssl-std.conf only solved half the problem. Bug 24937 suggests returning to the hardcoded origin file, but that restores the previous bogus situation. The subst list is a little more complex than the httpd-win.conf list, however we should be able to resolve this with a little awk magic. Reopening this bug to track the correct solution.
Problem solved with the 2.0.49 release, thanks for the report!