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 libtool.mk 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 libtool.mk 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 libtool.mk post autoconf) with no issues. Thoughts? Something I've got clearly wrong? Thanks, - Eric [1] https://github.com/macports/macports-ports/commit/7b23c55e903aa412f007b825e129e813a581b2ff#commitcomment-31890082