curl and libtool and --libs, oh my!

[Eric A. Borisch]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20190109/9df5d784/attachment.html>