curl-library
Re: Support for multiple SSL back-ends, first infrastructure changes
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