curl-users
Re: curl-config reports wrong info!
Date: Fri, 18 May 2001 08:45:25 -0500
On Fri, May 18, 2001 at 11:43:49AM +0200, Daniel Stenberg wrote:
> 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.
With the caveat that /usr/local/ssl gets stuck in LDFLAGS.
> > I suggest something like the following to replace *all* of the above
> > (untested):
> > EXTRA_SSL=
> >
> > case "$OPT_SSL" in
> > no) ;;
> > yes)
> > EXTRA_SSL=/usr/local/ssl ;;
> > *)
> > DEFAULT_SSL=$OPT_SSL ;;
> > esac
>
> 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.
You already have that. I'm not replacing the entire OPT_SSL section.
I'm just replacing:
AC_MSG_CHECKING(where to look for SSL)
if test X"$OPT_SSL" = Xoff
then
AC_MSG_RESULT([defaults (or given in environment)])
else
test X"$OPT_SSL" = Xyes && OPT_SSL=/usr/local/ssl
dnl LIBS="$LIBS -L$OPT_SSL/lib"
LDFLAGS="$LDFLAGS -L$OPT_SSL/lib"
CPPFLAGS="$CPPFLAGS -I$OPT_SSL/include/openssl -I$OPT_SSL/include"
AC_MSG_RESULT([$OPT_SSL])
fi
so you test for --with-ssl=no (--without-ssl):
if test X"$OPT_SSL" = Xno
then
AC_MSG_WARN(SSL/https support disabled)
else
remains intact.
> > 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, ,
> AC_CHECK_LIB(crypto, CRYPTO_lock,[
> LDFLAGS="$LDFLAGS -L$EXTRA_SSL/lib"
> 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
Ok, correct. The usual fix is to look for another symbol in -lcrypto
with the second AC_CHECK_LIB.
And, we should probably change the above to:
EXTRA_SSL=
case "$OPT_SSL" in
yes)
EXTRA_SSL=/usr/local/ssl ;;
esac
AC_CHECK_LIB(crypto, CRYPTO_lock,[
if test "x$OPT_SSL" != "xyes"; then
LDFLAGS="$LDFLAGS -L$OPT_SSL/lib"
CPPFLAGS="$CPPFLAGS -I$OPT_SSL/include/openssl -I$OPT_SSL/include"
fi],[
AC_CHECK_LIB(crypto, CRYPTO_lock,[
LDFLAGS="$LDFLAGS -L$EXTRA_SSL/lib"
CPPFLAGS="$CPPFLAGS -I$EXTRA_SSL/include/openssl -I$EXTRA_SSL/include"],
${EXTRA_SSL+-L${EXTRA_SSL}}),
${OPT_SSL+-L${OPT_SSL}}])
Anyway, I think it's time for a patch :)
-- albert chin (china_at_thewrittenword.com)Received on 2001-05-18