-----Original Message-----
From: curl-library-bounces_at_cool.haxx.se
[mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Daniel Stenberg
Sent: Friday, September 22, 2006 4:22 AM
To: libcurl development
Subject: RE: libcurl in LSB?

On Thu, 21 Sep 2006, Camp, TracyX E wrote:

> AFAIK, just that the library be a sort of (de-facto) standard, have
> documentation, tests and be stable (and as a project be committed to
> stability). Libcurl appears to be in pretty good shape on all fronts,

> though perhaps the tests could use some work.

Yeah, they could use some work indeed. But for a Linux-only environment
(which
LSB kind of implies) the test suite is pretty stable and good-working.
But I
would certainly not turn down any offers that would improve it!

Yes, LSB does sort of imply linux, but I believe some of the BSDs also
support LSB since some of the BSDs also can run linux binaries. I can't
promise anything right now (this is just an investigation at the
moment), but tests would possibly be something we would be helping with.

> One potential issue that pops out to me is ssl (a libcurl without SSL
> support is of fairly limit utility).

I don't quite agree that it would be "fairly limited" as it is still a
very
useful and powerful library for HTTP and FTP. Still, having it added to
LSB
without SSL would still be rather pointless since the majority of all
users
would like to replace that with an SSL-capable one...

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).

> LSB works by setting up a development environment that only includes
LSB
> interfaces. Part of doing so is wrapping linker commands and whatnot
to
> only allow shared libraries that are part of LSB to be linked in.

> OpenSSL is not yet in LSB (nor are any of the other SSL
implementations).
> This is something that I'm also working on, but it is in less 'good
shape'
> and is just plain a huge library.

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.

[experiment]
Build curl with the default config options (w/ ssl), make install.
Edit the makefile for curl itself and remove all of the -l statements
(-ssl -crypto -ldl -z in my case) except for libcurl. It should link
and run.

If you run 'readelf -d on /usr/local/lib/libcurl.so you should see a
number of (NEEDED) entries listing various shared libraries that
libcurl.so needs.

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.

This may entirely be a non-issue since it sorta looks like things are
already being done that way in your package.

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.

> I noticed a note about distributions not including your curl-config
tool
> (debian is one of these). Other than for picking up link args (which
for
> the reason discussed above may be problematic

Well, we are not responsible for what distros do or how they decide to
ship
curl and libcurl. We are simply the makers of the tool and lib, we do
not
create any packages used in Linux distros.

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

> > The curl_multi_socket() function is not yet deemed stable, but
otherwise
> > they should all be fine to use!
>
> Well if it is just the one API, mind if I ask what is preventing
stability
> here?

Just more testing and time. I intend to announce it as "stable" in the
7.16.0
release, which is the next public release we'll make.

Sounds great!

Thanks,

t.

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