i just subscribed to this list and only got this mail from this
thread, that is why i answer out of order

> On Wed, Jul 2, 2008 at 3:08 AM, Tor Arntsen <tor_at_spacetec.no> wrote:
>
> > On Wed, Jul 2, 2008 at 11:46 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> > > It is a debian thing (and a very recent debian change too): they started
> > to
> > > make their builds with a custom LDFLAGS settup.
> > >
> > > Possibly the curl way to have pkg-config and curl-config output LDFLAGS
> > when
> > > you ask for --libs is not very wise though, and the Debian fix for the
> > issue
> > > you mention seem to be to cut out LDFLAGS from the output of those two...
> > >
> > > I'm not yet 100% convinced that at least the curl-config change isn't
> > going
> > > to hurt someone.
> > >
> > > ... and besides (nudge nudge), we haven't seen the Debian guys submit any
> > > patches for this our way...

yes, my bad. we talked about it on irc, but i will try to make up for it now! :-)

this thread is about this patch:

Index: trunk/configure.ac
===================================================================
--- trunk.orig/configure.ac 2008-07-01 00:00:55.000000000 +0200
+++ trunk/configure.ac 2008-07-02 11:21:36.000000000 +0200
@@ -1005,7 +1005,8 @@
   if test -z "$GSSAPI_INCS"; then
      if test -f "$GSSAPI_ROOT/bin/krb5-config"; then
         GSSAPI_INCS=`$GSSAPI_ROOT/bin/krb5-config --cflags gssapi`
- GSSAPI_LIBS=`$GSSAPI_ROOT/bin/krb5-config --libs gssapi`
+ #GSSAPI_LIBS=`$GSSAPI_ROOT/bin/krb5-config --libs gssapi`
+ GSSAPI_LIBS="-lgssapi_krb5"
      elif test "$GSSAPI_ROOT" != "yes"; then
         GSSAPI_INCS="-I$GSSAPI_ROOT/include"
         GSSAPI_LIBS="-lgssapi"
@@ -1083,7 +1084,8 @@
         dnl krb5-config doesn't have --libs-only-L or similar, put everything
         dnl into LIBS
         gss_libs=`$GSSAPI_ROOT/bin/krb5-config --libs gssapi`
- LIBS="$LIBS $gss_libs"
+ #LIBS="$LIBS $gss_libs"
+ LIBS="$LIBS -lgssapi_krb5"
      elif test "$GSSAPI_ROOT" != "yes"; then
         LDFLAGS="$LDFLAGS -L$GSSAPI_ROOT/lib$libsuff"
         LIBS="$LIBS -lgssapi"
Index: trunk/libcurl.pc.in
===================================================================
--- 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@
 Libs.private: @LIBCURL_LIBS@ @LIBS@
 Cflags: -I${includedir}
Index: trunk/curl-config.in
===================================================================
--- trunk.orig/curl-config.in 2008-07-02 11:21:56.000000000 +0200
+++ trunk/curl-config.in 2008-07-02 11:23:51.000000000 +0200
@@ -195,14 +195,14 @@
           CURLLIBDIR=""
        fi
        if test "X_at_REQUIRE_LIB_DEPS@" = "Xyes"; then
- echo ${CURLLIBDIR}-lcurl @LDFLAGS@ @LIBCURL_LIBS@ @LIBS@
+ echo ${CURLLIBDIR}-lcurl @LIBCURL_LIBS@ @LIBS@
        else
+ echo ${CURLLIBDIR}-lcurl @LIBCURL_LIBS@ @LIBS@
        else
- echo ${CURLLIBDIR}-lcurl @LDFLAGS@ @LIBS@
+ echo ${CURLLIBDIR}-lcurl @LIBS@
        fi
        ;;

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

     *)

it is basicly the same solution in all the hunks, to very similar issues.

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configure scripts to determine the list of libraries that
it lib or app should link against. That system however is bogus.
It leads to ever growing dependency_libs lines without real
dependencies. That in turn will make systems much more fagile and
complex then necessary. That is why i blanked out the
dependency_libs line in libcurl.la for the debian packages
manually.

A library or application depending on libbar does not need to
link against libfoo just because libbar did. 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.

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.

On the other hand debians libcurl linked against a whole bunch of
kerberos related libs without using any of their symbols, just
because krb5-config would spit them out. the only lib really
needed (and used) was libgssapi_krb5.

While those unnecessary linked libs would just have made life
harder for developers (and systems) using libcurl the missing
symbol from libber would have caused a crash. Therefor i added
the

LDFLAGS = -Wl,-z,defs

in order to make the build of curl fail in the future if symbols
were missing.

pkg-config and curl-config also listed the LDFLAGS, which dont
really have any buissness in there. ELF takes care of knitting
together the libs and apps via symbol tables, and LDFLAGS of
other libs are not really interesting at linktime anymore.
Therefor i removed the LDFLAGS from both files.

> > Hm.. I see a problem that I can't immediately see a way out of:
> > Certainly just linking an application with -lcurl will work OK on
> > Debian, as libcurl itself is linked with all those necessary
> > libraries. But it won't work for our application, we create a
> > dynamically loadable module (an .so) for a plugin-application. This
> > module uses libcurl. When creating it with just the output from
> > curl-config --libs it will fail, because for this case what works for
> > applications won't work: We get missing symbols (from ssl symbols
> > etc.).

you should know which symbols from which libs your plugin needs
and link against those libs. dont rely on curl-config output to
take care of your depencies. the header files you need to include
in order to get it to compile are a good point to start when
figuring out those libs.

> > pkg-config --libs libcurl is no help either. So right now there
> > doesn't seem to be a simple way out of this, save for manually putting
> > together the library list.. not optimal.

it certainly is the right way, since there is no working
autodetection like you want it.
Received on 2008-07-03