On Fri, 22 Sep 2006, Camp, TracyX E wrote:

> While I will not dispute that HTTP and FTP cover a goodly amount of ground,
> the other part of LSB of course is convincing distributions to become
> compliant with it. I think it would be a hard sell to tell them that they
> couldn't ship a libcurl without SSL just for LSB compliance reasons (or
> possibly worse, they ship _two_ libcurls).

Right, but I don't understand how you can then add a libcurl with SSL support
without providing the SSL lib that installed libcurl will need...

> > Ok, so there's no SSL libs and libcurl is "fairly limited" without SSL.
> > Doesn't this basically imply that there must be an SSL lib provided first?
>
> Nope. Let me try and explain what I was trying to say again. (disclaimer: I
> only learned that this was possible quiet recently myself). On linux at
> least it is possible to create shared library link dependencies _on_ shared
> libraries. Poking at the curl distribution some more, it appears that it is
> actually doing this already.

...

> So basically the issue is that for LSB we can not (currently) require a top
> level application to link with ssl since it is not in the LSB, but it is
> perfectly okay for the distribution supplied libcurl that exports LSB
> interfaces to be linked with ssl.

You mean its fine for distros to put a SSL-capable libcurl in there even if
LSB really only has a SSL-disabled one?

> What I'm unsure about is what happens if libcurl is linked against openssl
> 0.9.8 and some other shared library in the LSB is linked against openssl
> 0.9.7 and then some application comes along and links against both of those
> shared libraries.

You get multiple symbols with the same names. That's one of the effects you'll
get by not including the SSL lib. I bet you can think of more tricky things
that might occur. To me, it sounds like a big can of worms. I wouldn't go
there.

>>> I noticed a note about distributions not including your curl-config
>>> tool

> > Well, we are not responsible for what distros do or how they decide to
> > ship
> > curl and libcurl.

> I understand. I was trying to determine if in your opinion this is a 'bad
> thing', or just 'a thing that some people do'.

We introduced curl-config since there was a need for it, and there are
numerous libcurl-using application packages out there in the world that now
use curl-config to detect details about libcurl installations (like from
within configure scripts), so yes I believe installing curl-config is a good
thing.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html