My experience was that 'patch' failed because the target _had already been patched_! (Because this is not the first run.) My strong recommendation is that the entire Apache source tree be removed, and reinstalled from the tar file, prior to _each_ mod_ssl configuration. Apache itself has problems with presistence of prior configuration states, and mod_ssl seems to get confused if Apache is not virgin. There may be some less drastic approaches that might work, but none has the simplicity and assured effectiveness of an 'rm -rf' and a 'tar'.
=== JJ ============================================================= On Sat, 6 Oct 2001, MindTerm wrote: > $ ./configure --with-apache=../apache_1.3.20/ > --with-openssl=../openssl-0.9.6b/ > Configuring mod_ssl/2.8.4 for Apache/1.3.20 > + Apache location: ../apache_1.3.20/ (Version 1.3.20) > + Auxiliary patch tool: ./etc/patch/patch (local) > + Applying packages to Apache source tree: > o Extended API (EAPI) > Error: Application of patch failed: > [....] > Patching file src/Configuration.tmpl using Plan A... > Hunk #1 failed at 26. > Hunk #2 succeeded at 495 with fuzz 2. > 1 out of 2 hunks failed--saving rejects to > src/Configuration.tmpl.rej > [....] > Patching file htdocs/manual/mod/directives.html using > Plan A... > Hunk #1 failed at 99. > 1 out of 1 hunks failed--saving rejects to > htdocs/manual/mod/directives.html.rej > > done > ------------------------------------------------- > Done: source extension and patches successfully > applied. > > Now proceed with the following commands (Bourne-Shell > syntax): > $ cd ../apache_1.3.20/ > $ SSL_BASE=/path/to/openssl ./configure ... > --enable-module=ssl > $ make > $ make certificate > $ make install > ______________________________________________________________________ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
