cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Support for multiple SSL back-ends, first infrastructure changes

From: Richard Atterer <richard_at_2005.atterer.net>
Date: Mon, 5 Sep 2005 14:46:38 +0200

On Mon, Sep 05, 2005 at 02:05:17PM +0200, Daniel Stenberg wrote:
> Well, when you check out the ssluse.c and gtls.c sources closer, you'll
> soon realize that they will be somewhat more complex than so, at least
> for some of the functions...

OK. :) It might take a few days for me to get back to working on this.

> >Hm, I'd rather keep the default of "yes". :-/ I fear that "no" will mean
> >that the "monolithic libcurl" will stay the predominant distributed
> >form, and that Debian will become binary incompatible to the rest of the
> >distros due to its use of "yes".
>
> Why would this make libcurl binary incompatible?

A binary which was built using a monolithic libcurl does (obviously) not
link against lib2, so when it is run on a system with a modular libcurl,
the run-time linker will not find the symbols provided by lib2. :-|

> >Maybe "yes" could be made the default with --prefix=/usr ? I don't
> >really like this idea, but it's better than nothing. Of course, the
> >configure script should print a big warning that the default setting is
> >changed.
>
> Nah, having it depend on the --prefix would be very strange and will only
> surprise users.

I'm inclined to agree, unfortunately... :-)

[automake conditionals]
> No, the if lines are converted to "real" makefiles at configure time so the
> generated makefiles no longer contain any ifs.

Right - I'll have a look at converting my patch to use this feature.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer     |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯
Received on 2005-09-05