curl and libtool and --libs, oh my!

Eric A. Borisch eborisch at
Thu Jan 10 05:25:58 UTC 2019

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.

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".

I built and tested curl with this approach (patching post
autoconf) with no issues.

Thoughts? Something I've got clearly wrong?

  - Eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the macports-dev mailing list