On Thu, 3 Jul 2008, Andreas Schuldei wrote:

Hey

I'm very happy you've brought these ugly lib issues into the light so that we
can discuss and deal with them. I'll just be frank and state it here clearly
from the beginning that you will find me reluctant of changing things like the
configure script since it is so vital and proven to actually work reasonably
well on a WIDE range of systems.

Also, I am often the only "protector" of all the older and legacy systems out
there as most of us who freuqent this list are Linux (and a few other modern
POSIX systems) users. Taken a curve a bit too sharpe on some of these issues
will lead to users hitting problems after next release on systems we thought
were extinct already 5 years ago.

So, I need to weight the dangers and problems with the current approach
compared to the possible problems the changes MAY impose to some users if we
persue them or don't persue them carefully enough.

Getting things to work reliably on Linux and even reliably on Debian are both
rather easy tasks in comparison.

> - GSSAPI_LIBS=`$GSSAPI_ROOT/bin/krb5-config --libs gssapi`
> + #GSSAPI_LIBS=`$GSSAPI_ROOT/bin/krb5-config --libs gssapi`
> + GSSAPI_LIBS="-lgssapi_krb5"

Surely this is a bug in the krb5-config? It should be made to only show us
what we need, in the same way curl-config should only do that.

The above change hardcodes the lib name where as the previous approach only
knows of the krb5-config tool.

Also, the above fix will break when you build libcurl to use a static krb5
lib.

> - LIBS="$LIBS $gss_libs"
> + #LIBS="$LIBS $gss_libs"
> + LIBS="$LIBS -lgssapi_krb5"

This has the same caveats.

> --- trunk.orig/libcurl.pc.in 2008-07-01 00:00:55.000000000 +0200
> +++ trunk/libcurl.pc.in 2008-07-02 11:21:36.000000000 +0200
> @@ -33,6 +33,6 @@
> URL: http://curl.haxx.se/
> Description: Library to transfer files with ftp, http, etc.
> Version: @VERSION@
> -Libs: -L${libdir} -lcurl @LDFLAGS@ @LIBS@
> +Libs: -L${libdir} -lcurl @LIBS@

Does the .pc file have a separate libs or ldflags alternative for when you
want to build with a static lib? Won't this change otherwise break static
builds?

> if test "X_at_REQUIRE_LIB_DEPS@" = "Xyes"; then
> - echo ${CURLLIBDIR}-lcurl @LDFLAGS@ @LIBCURL_LIBS@ @LIBS@
> + echo ${CURLLIBDIR}-lcurl @LIBCURL_LIBS@ @LIBS@

Really? I thought "REQUIRE_LIB_DEPS" was set exactly for the case when the
.elf file won't do the correct dependency thing and thus the app needs to link
with all the dependencies and not just libcurl and then it will also need the
LDFLAGS in case one or more lib is stored in a non-default place!

> --static-libs)
> - echo @libdir@/libcurl.@libext@ @LDFLAGS@ @LIBCURL_LIBS@ @LIBS@
> + echo @libdir@/libcurl.@libext@ @LIBCURL_LIBS@ @LIBS@

And same here. When you ask for the static libs, how will the linker find them
(without LDFLAGS) if libcurl was built with one of the libs in /tmp/foo/bar ?

> libtool puts all the libs that it was linked against into the
> "dependency_libs" line in the .la file. that file in turn is used by many?

I think this is one of the main flaws in your reasoning. AFAIK, hardly
anything is using that file when they link with external libs. As can be seen
in curl's configure script there's nothing that tries to or can use .la files
for linking.

> configure scripts to determine the list of libraries that it lib or app
> should link against. That system however is bogus.

The list is only valid for libcurl itself and for that it isn't bogus. I don't
think that field is meant to be exported or used by anything else.

> That is why i blanked out the dependency_libs line in libcurl.la for the
> debian packages manually.

But surely libcurl itself depends on those libs?

I don't think I understand libtool nor Debian enough to fully understand all
these aspects though.

> A library or application depending on libbar does not need to link against
> libfoo just because libbar did.

A "dependency" does in fact not imply "link directly". Example: the lib named
'A' links with lib 'B' that links with lib 'C'. The lib 'A' is then depending
on lib B+C but it only links with lib B.

> And if a given library or app needs symbols from libbar and relied on the
> libfoo.la file to list -lbar in its dependency_libs line to actually link
> against libbar would break in case libfoo stopped using and linking against
> libbar.

I agree. The system for how we for example assume that libber is magically
linked and used thanks to us using openldap's libldap is a bit disturbing. But
in this particular case of course, openldap's API is rather ugly and it itself
assumes/forces this presence and use of the second lib.

And of course, your patch didn't actually address any of these issues in the
curl conficure script. I'm sure we can detect at least one or two other cases
of this kind if we put a little effort into it.

This said, this is not really something that has hurt us much. In fact you're
the first one pointing this out and you're using Debian for which libcurl
builds and runs fine on...

> This kind of convenient autodetection as expected by many does not work
> reliably and therefor each lib or app are required to keep track of the
> libraries they directly depend upon. One such example where this broke was
> the libber line in the configure.ac patch above. There it was expected that
> libldap.la listed libber as a dependency in order for curl to link against
> it. but for some reason libber was not listed and debians curl never linked
> against libber anymore and would have crashed if it would have been used
> with ldap.

So installing openldap doesn't also magically install libber? How's that
supposed to work if not?

-- 
  / daniel.haxx.se