curl and libtool and --libs, oh my!

Joshua Root jmr at
Thu Jan 10 07:47:36 UTC 2019

On 2019-1-10 16:25 , Eric A. Borisch wrote:
> As discussed here [1] on GitHub, 'curl-config --libs' is returning
> results like this:
> -L/opt/local/lib -lcurl -lidn2 -lpsl -lssl -lcrypto -lssl -lcrypto -lz
> while 'pkg-config --libs libcurl' gives this:
> -L/opt/local/lib -lcurl
> The curl-config version results in lots of unnecessary libraries being
> linked against by the resulting binary. As a result, executables
> depending on libcurl (but not the underling lib API calls directly) can
> break (unnecessarily) if they use the curl-config --libs output when the
> underlying dependencies (like libidn2) change.

Libtool seems to overlink by design -- see our code to remove
dependency_libs in .la files after destrooting.

I guess it's sort of convenient from a certain point of view? Like "hey
why are these zlib symbols I'm using not found, I'm linking with libpng
which depends on zlib!" It gets a lot less convenient when you have to
maintain a distro.

> It looks like FreeBSD takes the approach (linked in the GitHub comments)
> of modifying libtool's <> to change its
> link_all_deplibs behavior (to "no") for a number of ports (any with
> 'using libtool'.)
> Ubuntu does something similar to end up with a crow-barred clause of 'if
> test "Xno" = "Xyes"; then' in curl-config such that --libs returns
> '-lcurl' alone; I haven't tracked down their actual build scripts for this.
> RedHat 6 (I haven't checked 7) changes curl-config --libs to just call
> 'pkg-config --libs libcurl' directly.
> Any thoughts on how to resolve this? Take the FreeBSD/Ubuntu approach of
> patching <> at some point (for all ports?
> for just curl?) to say link_all_deplibs="no"? Every OS on upstream GNU
> libtool returns "yes" or "unknown" (="yes"), and you can google for
> link_all_deplibs Debian to see some discussions of the pros and cons of
> "no".

It doesn't help that libtool's documentation gives this unhelpfully
ambiguous definition of what link_all_deplibs means: "Whether libtool
must link a program against all its dependency libraries." OK, sure, but
what about whether it must link against all the dependencies'
dependencies as well?

Curl can be fixed with a simple patch to the configure script. I'm not
sure if we should try to do something about libtool in general; it's no
good fixing things there if we have to autoreconf the whole world to
actually have the fix used. And we'll be fighting upstream's apparent
design philosophy as well.

- Josh

More information about the macports-dev mailing list