cURL / Mailing Lists / curl-users / Single Mail

curl-users

Re: curl-config reports wrong info!

From: <curl_at_thewrittenword.com>
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