Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

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.

[Followed up on Github curl bug tracker and may have patch, but subsequent
problems building tests, which KB may know something about, so moving to
cygwin-apps]

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]