Re: [ANNOUNCEMENT] Updated: curl 7.71.1-2

[Adam Dinwoodie <adam@dinwoodie.org>]

On Sat, 15 Aug 2020 at 23:45, Brian Inglis wrote:
>
> On 2020-08-11 16:00, Brian Inglis wrote:
> > On 2020-08-11 05:27, Adam Dinwoodie wrote:
> >> 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.
> >
> > I'll copy these comments and suggestions and follow up there, as that appears to
> > be the official bug tracker, and they appear receptive to discussing and fixing
> > issues.
> >
> >> 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.
> >
> > I did not see or get your original email, and could not reproduce your issue
> > using the current git source package, curl package, and cygport.
> > That could be due to two missing perl modules (solved in another sub-thread by
> > Achim).
> > Any suggestions as to what may be required to get curl-config to act up in a
> > build would be appreciated.
> > It is always easier to check if a problem is actually fixed when you can perform
> > an in situ regression test.
> > Running curl-config and reading the docs, it does not appear to me to be clearly
> > specified why and when dynamic and static library parameters are either built in
> > or generated, whereas the conditions for reproducing the output are well
> > specified for pkgconf/pkg-config.
> > That may become more apparent in follow ups on the bug tracker.
>
> Got help from Ken Brown on Github curl/curl autotools file patches and applied
> to upgraded curl 7.71.1-2 which fix the curl-config --libs issues and a make
> check test library build issue.
> Please update your curl and libcurl-devel packages and retry your builds.
> Patches should be applied upstream and included in next official curl release,
> so we should be able to drop local Cygwin patches, allowing you to more easily
> build your own Cygwin curl releases from upstream sources should you so desire.
> Also cygport update, patches, etc. are in the source package and have also been
> pushed to:
>
>         https://cygwin.com/git/?p=git/cygwin-packages/curl.git;a=summary
>
> FYI and if you want to plan any customizations to Cygwin sources.

Confirmed this resolves the Git build issues. Thank you!