Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Adam Dinwoodie <adam@dinwoodie.org>]

On Tue, 11 Aug 2020 at 12:14, Ken Brown via Cygwin wrote:
> > In that case, it looks to me as if the generated curl-config --libs statements:
> >
> >          if test "Xyes" = "Xno" -o "Xyes" = "Xyes"; then
> >            echo ${CURLLIBDIR}-lcurl -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto
> > -lldap -llber -lbrotlidec -lbrotlidec -lz
> >
> > based on curl-config.in:
> >
> >          if test "X@ENABLE_SHARED@" = "Xno" -o "X@REQUIRE_LIB_DEPS@" = "Xyes"; then
> >            echo ${CURLLIBDIR}-lcurl @LIBCURL_LIBS@
> >
> > REQUIRE_LIB_DEPS should be no, derived from configure.ac:
> >
> > if test "X$enable_shared" = "Xyes" -a "X$link_all_deplibs" = "Xno"
> > then
> >      REQUIRE_LIB_DEPS=no
> > else
> >      REQUIRE_LIB_DEPS=yes
> > fi
> > AC_SUBST(REQUIRE_LIB_DEPS)
> > AM_CONDITIONAL(USE_EXPLICIT_LIB_DEPS, test x$REQUIRE_LIB_DEPS = xyes)
> >
> > but for Cygwin link_all_deplibs remains defaulted to unknown, so either that
> > variable should be set in configure, or that condition should perhaps be changed
> > to:
> >
> > if test "X$enable_shared" = "Xyes" -a "X$link_all_deplibs" != "Xyes"
> >
> > with appropriate bug reports and changes to be made upstream if possible.
>
> If you want to look into ways of fixing curl-config different from what Yaakov
> did, that's fine; you're the maintainer.  All I did was look at Yaakov's patch
> and port it to curl 7.71.1, that being a quick and easy way to fix the reported
> problem.

Someone else did raise this problem upstream at
https://github.com/curl/curl/issues/5793, and the comments there imply
they'd be interested in integrating patches Cygwin uses into the
upstream code, although the upstream maintainers aren't going to do
that without someone proactively submitting the patch to them.

For my part, I'm not particularly fussed whether this is fixed with an
upstream patch or a Cygwin patch; I just want my use cases to work,
and as of 7.71.1-1 they don't. That said, my experience of being a
package maintainer would lead me to want to submit patches upstream if
at all possible, just to reduce the need to handle these sorts of
problems. My inclination would be to restore the patched behaviour
with Ken's new patch as a short-term fix, then get this submitted
upstream so that in the long-term this patch can be retired.