On Thu, May 17, 2001 at 03:48:07PM +0200, Daniel Stenberg wrote:
> On Thu, 17 May 2001, Domenico Andreoli wrote:
> > during ./configure curl-config.in (which is a shell script, you all know)
> > gets transformed in curl-config. all this script does is printing the
> > $CFLAGS $LDFLAGS and the like that configure is putting in Makefiles.
> > when i compile curl with ssl on my debian system i don't need to specify
> > anything but --with-ssl on configure commandline since my developing
> > anvironment is already set up for compiling the right way with ssl
> > libraries. the matter is the configure thinks it is getting ssl stuff
> > from /usr/local/ssl... you know where i'm going, curl-config will
> > eventually say to get includes and libs from /usr/local/ssl.
> Hm, actually, curl-config is not wrong (by my definition). I can't be wrong,
> it just shows what the contents of the variables in configure are/were at the
> time it ran. If the curl-config data ends up wrong, it is because the
> configure script is wrong.
> The problem is thus that the configure script sets up paths for SSL to
> directories that aren't correct or needed. Right?
> But then, if you use --with-ssl for configure, it _will_ add those
> directories. If you have your defaults in your environment already setup
> correctly, then you shouldn't even need the --with-ssl option (since curl's
> configure script will always check for the presense of ssl in the default
If someone uses --with-ssl rather than --with-ssl=DIR, *nothing*
should be added to LDFLAGS, LIBS, CPPFLAGS, etc. Either something like
AC_CHECK_LIB(crypto, CRYPTO_lock) will work in this case or not.
> > i see that for kerberos you can specify separate includes and libs
> > directories, i think that a feature like this for ssl stuff would let me
> > build everything as i (and debian) need.
> I don't think I've fully understood how you're doing things. You mean you
> need parts of the stuff configure sets up on --with-ssl but not everything?
> Please tell me where I'm wrong and what I've failed to grasp!
Here's the problem (BTW, --with-ssl=off is a currently workaround to
this problem) in configure.in:
AC_MSG_CHECKING(where to look for SSL)
if test X"$OPT_SSL" = Xoff
AC_MSG_RESULT([defaults (or given in environment)])
test X"$OPT_SSL" = Xyes && OPT_SSL=/usr/local/ssl
dnl LIBS="$LIBS -L$OPT_SSL/lib"
CPPFLAGS="$CPPFLAGS -I$OPT_SSL/include/openssl -I$OPT_SSL/include"
If --with-ssl is given but no path is specified as to the location of
the SSL libraries, OPT_SSL=/usr/local/ssl. If someone has the ssl
stuff in /lib, what do they do? They don't need to do anything as
AC_CHECK_LIB(crypto, CRYPTO_lock) will check in /lib but you've now
inadvertently added /usr/local/ssl/lib to LDFLAGS and
/usr/local/ssl/include/openssl and /usr/local/ssl/include to CPPFLAGS.
That is wrong.
I suggest something like the following to replace *all* of the above
case "$OPT_SSL" in
dnl Quick check to decide if we need $EXTRA_SSL
AC_CHECK_LIB(crypto, CRYPTO_lock, ,
CPPFLAGS="$CPPFLAGS -I$EXTRA_SSL/include/openssl -I$EXTRA_SSL/include,
dnl check for crypto libs (part of SSLeay)
BTW, a few comments on your use of $ac_... variables:
1. Much preferable to use the ACTION-IF-NOT-FOUND part of a macro
2. You don't need
dnl If all heades are present, we have enabled SSL!
if test "$ac_cv_header_openssl_x509_h" = "yes" &&
test "$ac_cv_header_openssl_rsa_h" = "yes" &&
test "$ac_cv_header_openssl_crypto_h" = "yes" &&
test "$ac_cv_header_openssl_pem_h" = "yes" &&
test "$ac_cv_header_openssl_ssl_h" = "yes" &&
test "$ac_cv_header_openssl_err_h" = "yes"; then
dnl Check the alternative headers too
if test "$ac_cv_header_x509_h" = "yes" &&
test "$ac_cv_header_rsa_h" = "yes" &&
test "$ac_cv_header_crypto_h" = "yes" &&
test "$ac_cv_header_pem_h" = "yes" &&
test "$ac_cv_header_ssl_h" = "yes" &&
test "$ac_cv_header_err_h" = "yes"; then
Just augment your AC_CHECK_HEADERS macro above with:
dnl Check for SSLeay headers
AC_CHECK_HEADERS(openssl/x509.h openssl/rsa.h openssl/crypto.h \
openssl/pem.h openssl/ssl.h openssl/err.h,
AC_CHECK_HEADERS(x509.h rsa.h crypto.h pem.h ssl.h err.h,
albert chin (china_at_thewrittenword.com)
Received on 2001-05-18