Re: Support for multiple SSL back-ends, first infrastructure changes
Date: Mon, 5 Sep 2005 00:35:38 +0200 (CEST)
On Sun, 4 Sep 2005, Richard Atterer wrote:
> the attached patch is my first go at supporting the "lib2" approach
> described in <http://curl.haxx.se/legal/distro-dilemma.html>. This doesn't
> yet do anything useful, but I'm posting it to ask people (in particular
> Daniel;) whether they agree that this is the right way to do it.
I agree to the general approach, as far as I've understood it! ;-)
> There is now provision to optionally build three separate libs called
> (I'm open to suggestions for different names.)
I want to have it named separately from "libcurl" to make it very clear that
it isn't libcurl, but a lib that libcurl would use. Possibly "libsectra" for
This lib would also get its own set of API/headers etc and there is a risk
that it will start living its own life if it becomes good...!
> - Do not include compiler switches specific to an SSL lib in the
> global make variables. Whereas previously e.g. "-lssl" was added to
> $LIBS in the configure script, now it is added to OPENSSL_LIBS. The
> following variables exist and are AC_SUBSTed: OPENSSL_LDFLAGS
> OPENSSL_CFLAGS OPENSSL_LIBS GNUTLS_LDFLAGS GNUTLS_CFLAGS
But how would a regular app get the options needed to link with libcurl and
lib2? I guess it would need to specify which lib2 with curl-config and get
the options for that specificly?
> - new switch --with-separate-libs (default: yes) controls contents of
> SEPARATE_LIBS. You can actually supply a space-separated list of
> lib names (e.g. --with-separate-libs='nossl openssl'), but that
> feature shouldn't really be used with the SSL libs, because as soon
> as more one lib out of "nossl openssl gnutls" is built separately,
> _all_ of the others must also be built separately.
I think it makes sense to have this default set to no to start with. I suspect
that most people who build libcurl from source won't be interested in this
extra layer of complexity.
> The sources need to be split according to which libcurl-ssl*.la they end up
> in. Unfortunately, I did not find a way to avoid that you also have to
> specify a list of object files for each separate lib. Not sure yet whether
> ".lo" or ".$(OBJEXT)" (i.e. ".o") is the right extension. The automake docs
> list the latter, but then automake warns about the ".o" being non-portable.
I don't see why you need to resort to object files, but then I didn't try this
magic myself (yet). Why doesn't just adding up the source files for each lib
> * The CVS configure.ac (or another auto* file) fails with libtool 1.6, I
> had to downgreade to 1.4 or 1.5. With 1.6, you get the following error
> during "autoconf".
Sigh. Ok, thanks for pointing this out. Seems I'll get myself a fun project to
fix this then! :-/
-- Commercial curl and libcurl Technical Support: http://haxx.se/curl.htmlReceived on 2005-09-05