curl and libtool and --libs, oh my!
Eric A. Borisch
eborisch at macports.org
Thu Jan 10 05:25:58 UTC 2019
As discussed here  on GitHub, 'curl-config --libs' is returning results
-L/opt/local/lib -lcurl -lidn2 -lpsl -lssl -lcrypto -lssl -lcrypto -lz
while 'pkg-config --libs libcurl' gives this:
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the macports-dev