Re: curl-config reports wrong info!
Date: Fri, 18 May 2001 11:43:49 +0200 (MET DST)
On Fri, 18 May 2001 curl_at_thewrittenword.com wrote:
> > But then, if you use --with-ssl for configure, it _will_ add those
> > directories.
> 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.
Then what would configure do if --with-ssl is not specified? I like the fact
it tries to find it anyway, as configure should be a tool that sets up the
build environment in the best possible way.
I also find it comfortable to specify "--with-ssl" when I have OpenSSL
installed in its default install path and thus I don't have to think about
exactly where OpenSSL is installed.
> Here's the problem (BTW, --with-ssl=off is a currently workaround to this
> problem) in configure.in:
Yeah, or if you write it "--without-ssl".
> 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 just run "./configure" and it'll find ssl by magic.
> I suggest something like the following to replace *all* of the above
> case "$OPT_SSL" in
> no) ;;
> EXTRA_SSL=/usr/local/ssl ;;
> DEFAULT_SSL=$OPT_SSL ;;
This wouldn't do. We need an explicit way to tell it not to use SSL. Mostly
needed for people building binary packages when they have SSL installed but
wants to build a non-ssl version of the package.
> dnl Quick check to decide if we need $EXTRA_SSL
> AC_CHECK_LIB(crypto, CRYPTO_lock, ,
> AC_CHECK_LIB(crypto, CRYPTO_lock,[
> LDFLAGS="$LDFLAGS -L$EXTRA_SSL/lib"
> CPPFLAGS="$CPPFLAGS -I$EXTRA_SSL/include/openssl -I$EXTRA_SSL/include,
> , -L$EXTRA_SSL/lib]))
I'm afraid this doesn't work. I made this test:
dnl check for crypto libs (part of SSLeay)
AC_CHECK_LIB(crypto, CRYPTO_lock, ,
CPPFLAGS="$CPPFLAGS -I$EXTRA_SSL/include/openssl -I$EXTRA_SSL/include"
... the problem is that AC_CHECK_LIB() result is cached and thus the second
test is never evaluated:
checking for CRYPTO_lock in -lcrypto... no
checking for CRYPTO_lock in -lcrypto... (cached) no
> BTW, a few comments on your use of $ac_... variables:
Ah, thanks for that. Makes the script a lot nicer!
-- Daniel Stenberg -- curl dude -- http://curl.haxx.se/Received on 2001-05-18