cURL / Mailing Lists / curl-library / Single Mail


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

From: Richard Atterer <>
Date: Mon, 5 Sep 2005 17:12:39 +0200

On Mon, Sep 05, 2005 at 03:20:03PM +0200, Daniel Stenberg wrote:
> Right, but a binary - as in an application using libcurl - will never use
> symbols provided by lib2 directly, only libcurl will do that. So, if the
> binary is linked to use libcurl it should do just that.
> I'll admit that I'm not quite sure how the run-time linker will act if an
> application is linked and claimed to need a lib and then the lib doesn't
> exist and no symbols are needed from it...

I think will fail with an error message.

AFAIK, the following will happen:

1) App built with monolithic libcurl, attempt to run using "libcurl &
separate libs" fails: cannot find e.g. lib2_ssl_connect. That symbol
is referenced from the of "libcurl & separate libs", but we
cannot make link directly against lib2 (due to the GPL vs
OpenSSL license stuff).

2) App built with "libcurl & separate libs", attempt to run using
monolithic libcurl fails: All symbols are there, but the app binary
contains (so to speak) a "-llib2"; a reference to one of the lib2 libs.
None of these lib2 libs are available.

I think the link failure for 1) could be avoided by making the
lib2_ssl_connect symbol a "weak" symbol. But then running the app would
fail: Any attempt to actually call lib2_ssl_connect() would give a
segfault. (&lib2_ssl_connect would be 0)

I haven't found a way to avoid the failure of 2).

BTW, note that it is certainly an option to just say "let's not care about
cross-distro compatibility for this case" because similar incompatibilities
will arise if libcurl has SSL support on some distros and no SSL support on
others. *shrug*


  __   _
  |_) /|  Richard Atterer     |  GnuPG key:
  | \/|  |  0x888354F7
Received on 2005-09-05