./configure --with-static-libs
...
checking for curl_global_init in -lcurl... no
configure: error: Cannot actually use libcurl; try specifying --without-libcurl.

Works fine if I don't try to build statically.  The libcurl.a library
comes from Debian's libcurl4-openssl-dev.

                                        Juliusz

Still the case with 2.0.0 + 108 patches
Have contacted Dmitry Kurochkin, who may know what to do about this.

The configure script passes for me... maybe it's gotten accidentally fixed?

I do get the following warnings when linking a static darcs-2:

Linking darcs ...
/usr/lib/libcurl.a(ldap.o): In function `Curl_ldap':
(.text+0x4bf): warning: Using 'dlopen' in statically linked applications
requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/libcurl.a(netrc.o): In function `Curl_parsenetrc':
(.text+0x3a1): warning: Using 'getpwuid' in statically linked applications
requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/libgssapi_krb5.a(import_name.o): In function `krb5_gss_import_name':
(.text+0x308): warning: Using 'getpwuid_r' in statically linked applications
requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/libcurl.a(hostip6.o): In function `Curl_getaddrinfo':
(.text+0x12f): warning: Using 'getaddrinfo' in statically linked applications
requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/libkrb5.a(cc_memory.o): In function `krb5_mcc_generate_new':
(.text+0x13e8): warning: the use of `mktemp' is dangerous, better use `mkstemp'
/usr/lib/network-2.0/ghc-6.6/libHSnetwork-2.0.a(BSD__155.o): In function
`sqZy_info':
(.text+0x105): warning: Using 'gethostbyname' in statically linked applications
requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/libkrb5.a(hostaddr.o): In function `krb5_os_hostaddr':
(.text+0xb5): warning: Using 'gethostbyname_r' in statically linked applications
requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/libcurl.a(connect.o): In function `singleipconnect':
(.text+0x30f): warning: Using 'getprotobyname' in statically linked applications
requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/libkrb5.a(send524.o): In function `krb5int_524_sendto_kdc':
(.text+0x67): warning: Using 'getservbyname' in statically linked applications
requires at runtime the shared libraries from the glibc version used for linking

I've no idea whether or not this is serious.

David, what libcurl Debian package are you using? [I assume you're using one]. 
I'm also using the libcurl4-openssl-dev (Ubuntu Gutsy)

$ aptitude show libcurl3-dev
Package: libcurl3-dev
State: installed
Automatically installed: no
Version: 7.15.5-1etch1
Priority: optional
Section: libdevel
Maintainer: Domenico Andreoli <cavok@debian.org>
Uncompressed Size: 28.7k
Depends: libcurl3-openssl-dev (= 7.15.5-1etch1)
Replaces: libcurl-dev, libcurl-ssl-dev
Provides: libcurl-dev, libcurl-ssl-dev
Description: Transitional package to libcurl3-openssl-dev
 Transitional package depending on libcurl3-openssl-dev.

 Once installed, this package may be safely removed.

 Homepage: http://curl.haxx.se

But I also discovered that my statically linked binary won't run on a sarge
system, so it's not much use.

I have tried to compile --with-static-libs on debian unstable and configure failed.
It looks like to compile with static libcurl you should use options from
curl-config --static-libs. I have changed configure.ac to use it and configure
script still fails :) But with a single error:

/usr/bin/ld: cannot find -lgssapi_krb5
collect2: ld returned 1 exit status

After some debian bts search I have found the following bug:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=439039

Basically it says that krb5 static lib is not built anymore. So it looks like I
can not use static libcurl from debian (this may be a libcurl package bug BTW).
And I do not have time to build my own libcurl at the moment.

I attach the patch to curl-config --static-libs. It is not a darcs patch, sorry.
But I was not able to download darcs unstable with my debian darcs1. Is there
only darcs2 repo left? I will try to get back to this in few days (but can not
promise that). But that would be great if someone who has working static libcurl
test it.

Also David mention that he has configure successfully passed. If this is already
fixed, sorry for the noise.

Regards,
  Dmitry

Attachments

• curl_static.patch

Dmitry: Many thanks for looking into this!

Could you maybe upgrade your darcs with this source tarball
http://darcs.net/darcs-2.0.0.tar.gz and submit a darcs patch?

I have sent darcs patch. Testing is welcomed!

Thanks!  But with this patch, I still get

checking for curl_global_init in -lcurl... no
configure: error: Cannot actually use libcurl; try specifying --without-libcurl.

This time, on Ubuntu Hardy, with

$ aptitude search libcurl
p   gimp-libcurl                      - libcurl URI plugin for GIMP
v   libcurl-dev                       -
p   libcurl-ocaml                     - ocaml curl bindings
p   libcurl-ocaml-dev                 - ocaml libcurl bindings
v   libcurl-ssl-dev                   -
i   libcurl3                          - Multi-protocol file transfer
library (OpenSS
p   libcurl3-dbg                      - libcurl compiled with debug
symbols
v   libcurl3-dev                      -
i A libcurl3-gnutls                   - Multi-protocol file transfer
library (GnuTLS
v   libcurl3-gnutls-dev               -
v   libcurl3-openssl-dev              -
v   libcurl4-dbg                      -
v   libcurl4-dev                      -
p   libcurl4-gnutls-dev               - Development files and
documentation for libc
i   libcurl4-openssl-dev              - Development files and
documentation for libc

What do you see in config.log? I am pretty sure ubuntu has the same libcurl bug
as debian.

Ah yes, you did point this out:

configure:6771: checking for libcurl
configure:6786: result: 7.18.0
configure:6803: checking for curl_global_init in -lcurl
configure:6838: gcc -o conftest  -O2  -DCURL_STATICLIB
-DHAVE_BYTESTRING -DHAVE_CUR
L -static  /usr/lib/libcurl.a -lgssapi_krb5 -lidn -lssl -lcrypto
-lldap -L/usr/lib -
lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lssl -lcrypto -lz conftest.c
-lcurl  -DCUR
L_STATICLIB /usr/lib/libcurl.a -lgssapi_krb5 -lidn -lssl -lcrypto
-lldap -L/usr/lib
-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lssl -lcrypto -lz  -lz >&5
/usr/bin/ld: cannot find -lgssapi_krb5
collect2: ld returned 1 exit status

I guess I'll be marking this as not-our-bug, then (provided your patch
is applied)

If this is 'not-our-bug', can it be closed as either 'resolved' or 'wont-fix' ?

This is the kind of situation that I don't know how to deal with on the bug
tracker.  Indeed, it is not our bug -- we cannot do very much about it -- but it
is also somewhat important to us, because the ability to build statically linked
darcs is useful for the project.

I suspect that part of the problem is that we are (implicitly) transitioning
from not providing and supporting binaries and wanting to support them a little
bit more.

So what do we do here?  Is it appropriate to keep this issue around (the task
being to check up on the Debian people for a potential solution to the inability
to build static darcs 2?)

IMHO this is a debian bug. It has nothing to do with darcs. You can build static
darcs with a working static libcurl (and I think it is a good idea to provide
static windows binaries on the official site).

Debian provides broken static libcurl. I think we should file a bug on the
debian BTS and close this bug.

Would it be a different bug than the one you pointed out?
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=439039

They seem quite pessimistic :-/

Yes, that would be different. I think we should file a bug against curl.
Solution is to build static libcurl without kerberos. But I am not sure if this
is easy/possible in debian. Perhaps debian maintainer would find a better fix.

Hi Trent,

I seem to recall you being our contact in the Debian community :-)
If so, would you be willing to file a bug against curl for this?

On Wed, Aug 13, 2008 at 11:16:42AM -0000, Eric Kow wrote:
> I seem to recall you being our contact in the Debian community :-)
> If so, would you be willing to file a bug against curl for this?

Strictly speaking, I'm in charge of integrating Darcs into Debian,
rather than a more general "liason".  Since the darcs .debs don't
involve static linking, I normally wouldn't be reponsible for chasing
up the libcurl/libkrb maintainers.  That'd normally be the
responsibility of the person trying to statically build darcs (Dmitry,
if I read #806 correctly).

In this instance (because I was bored), I've reported the bug against
libcurl4-openssl-dev on his behalf, as

    http://bugs.debian.org/495163

I've also sent a subscribe request, spoofed from Dmitry, so he can
track the bug more easily.  In particular, he'll receive notification
when the bug is closed.  (I can't just subscribe this #806 to the
#495163 list, because mail via the Debian BTS wouldn't have [issue806]
at the start of the Subject header field.)

On Fri, Aug 15, 2008 at 11:37:09AM +1000, Trent W. Buck wrote:
> In this instance (because I was bored), I've reported the bug
> against libcurl4-openssl-dev on his behalf, as
> 
>     http://bugs.debian.org/495163

The curl people say it probably isn't their fault, and that darcs
probably needs gssapi-krb for something else.

On my Ubuntu Hardy box:

$ curl-config --static-libs
/usr/lib/libcurl.a -lgssapi_krb5 -lidn -lssl -lcrypto -lldap -L/usr/lib
-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lssl -lcrypto -lz

I am pretty sure that gssapi-krb is not needed by darcs itself.

I will do some more testing/investigation and post a reply to the debian bug.