On Fri, 19 Aug 2005, Richard Atterer wrote:

> Daniel, it'd be great if the problem were solved by you as upstream, in a
> way which also solves it for Debian (and other distros). That way, the
> chances of cross-distro binary compatibility of libcurl will be much better!

I appreciate your efforts and clear thinking. Let's see what we can do to work
things out. There might just as well be other linux and BSD distros that might
benefit from this too.

> First, try to understand the Debian POV for this. Assume the following:
>
> - Future versions of curl will offer different features depending on
> whether they're built with OpenSSL or GnuTLS, or both.

Both is interesting. Currently libcurl doesn't support both, just one at a
time. Of course it shouldn't be very difficult to do. The SSL layer is
reasonably abstracted already.

I guess this is the key to success here, that we make this supported. Call me
thick, but I didn't quite think of that before.

> My proposed solution:
>
> Always build and install just one libcurl.so. Building two versions might be
> OK as a short-term solution, but it invites all sorts of "fun" for program A
> above, which would link against two /almost/ identical versions of the same
> code.
>
> The trick: Create your own "libcurl-ssldummy.so" version of OpenSSL. It
> provides symbols for the entire OpenSSL API, but returns an error if any
> function is called.

If we add support for linking with both at once, then such a trick could
easily be done by a packager of libcurl. I don't think we in this project need
to do anything particular to support this. Other than perhaps make the code
deal with such a situation in a suitable way.

> In the next step, make curl-config output the right library switches:
>
> - When program A (BSD, uses OpenSSL+GnuTLS) is built, it just uses the
> regular "curl-config --libs" to get its linker flags. It gets back -lssl
> (and friends), -lgnutls (and friends) or none of these two, depending on
> whether libcurl was built with(out) OpenSSL/GnuTLS support.
>
> - When program B (GPL-licensed) is built, it passes a special switch to
> curl-config, e.g. "curl-config --libs --no-openssl". It gets the same
> flags as without the --no-openssl switch, EXCEPT that -lssl and friends
> have been replaced with "-lcurl-ssldummy".
>
> B will link just fine using the dummy SSL library. When the B binary is
> run, it is *not* linked against OpenSSL at all.

Right, if you use curl-config to get the options we either need a special
option like this (or there needs to be two curl-config scripts).

Just an option that does sed -e "s/-lssl -lcrypto/-lcurl-ssldummy/" seems easy
enough.

> From the POV of libcurl: libcurl should determine during runtime whether
> OpenSSL is really available, e.g. by checking for a special return value of
> SSL_get_version(). If it is available, use it, otherwise fall back to
> GnuTLS, or let the program choose.

Yes, I believe you have a solution that should work rather nicely.

Thanks again.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html