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 ld.so 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: ld.so cannot find e.g. lib2_ssl_connect. That symbol
is referenced from the libcurl.so of "libcurl & separate libs", but we
cannot make libcurl.so 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

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