I am trying to link libcurl with my application and I get the following when
i do ld or ldd on the binary I build.

ld issues
/usr/local/lib/libcurl.so.4: no version information available

ldd issues
: undefined reference to `curl_global_cleanup_at_CURL_OPENSSL_3'
: undefined reference to `curl_easy_cleanup_at_CURL_OPENSSL_3'
: undefined reference to `curl_easy_perform_at_CURL_OPENSSL_3'
: undefined reference to `curl_slist_free_all_at_CURL_OPENSSL_3'
: undefined reference to `curl_easy_setopt_at_CURL_OPENSSL_3'
: undefined reference to `curl_formadd_at_CURL_OPENSSL_3'
: undefined reference to `curl_easy_init_at_CURL_OPENSSL_3'
: undefined reference to `curl_slist_append_at_CURL_OPENSSL_3'
: undefined reference to `curl_global_init_at_CURL_OPENSSL_3

I have installed curl manually using the ./configure , make , make install

and I have libcurl.so and libcurl.so.4 in /usr/local/lib.

Any pointers on whats going on wrong?

Thanks

On Mon, Jul 7, 2008 at 12:12 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> 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
>
Received on 2008-07-17