checking for OpenSSL library ... not found
noloader at gmail.com
Tue Dec 17 10:16:15 UTC 2013
So, looking into this more, it looks like the configure subsytem is
not flexible enough to handle OpenSSL with customizations. The problem
appears to be in auto/lib/conf, with some hard coded values around
In my case, the path is not standard (i.e, /usr/include); and I do not
desire just any libssl or libcrypto (i.e., I want a particular version
of the static libraries from a certain location).
I think the best way to proceed is to patch conf and then fix whatever
problems may surface later. I know OpenSSL's FIPS is likely going to
be a problem when I have to use fipsld and incore for backpatching
signatures, but that's par for the course.
Does this sound reasonable? Or should I try to figure out a way to
make "ngx_feature_path" and "ngx_feature_libs" more helpful?
On Mon, Dec 16, 2013 at 7:12 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> checking for OpenSSL library ... not found
> ./auto/configure: error: SSL modules require the OpenSSL library.
> You can either do not enable the modules, or install the OpenSSL library
> into the system, or build the OpenSSL library statically from the source
> with nginx by using --with-openssl=<path> option.
> I believe OpenSSL is present (I just built it from sources):
> $ ls /usr/local/ssl/
> bin certs include lib man misc openssl.cnf private
> $ ls /usr/local/ssl/lib/
> engines libcrypto.a libssl.a pkgconfig
> Here was my configure. $THIS_USER and $THIS_GROUP was set properly to
> my login and group.
> ./auto/configure --with-debug --with-http_ssl_module
> --prefix="$THIS_DIR/ac" --http-proxy-temp-path="$THIS_DIR/ac/temp"
> --user="$THIS_USER" --group="$THIS_GROUP"
> /usr/local/ssl/lib/libssl.a /usr/local/ssl/lib/libcrypto.a
> I believe --with-cc-opt and --with-ld-opt is the preferred (required?)
> way to do things for local/custom OpenSSL
> Does anything look out of place?
More information about the nginx