[ANNOUNCEMENT] Updated: curl 7.71.1-1

[Ken Brown]

On 8/15/2020 5:32 PM, Brian Inglis wrote:
> On 2020-08-14 13:36, Ken Brown via Cygwin-apps wrote:
>> On 8/14/2020 2:45 PM, Brian Inglis wrote:
>>> On 2020-08-14 12:19, 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.
>>>>
>>>> [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]
>>>
>>> Test build failures - tried adding to cygport:
>>>
>>> src_test() {
>>>           cd ${B}
>>>           cygtest LDFLAGS="${LDFLAGS} -no-undefined"
>>> }
>>>
>>> but no change:
>>>
>>> Making all in libtest
>>> make[2]: Entering directory
>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/libtest'
>>>     CCLD     libstubgss.la
>>> libtool:   error: can't build x86_64-pc-cygwin shared library unless
>>> -no-undefined is specified
>>> make[2]: *** [Makefile:2547: libstubgss.la] Error 1
>>> make[2]: Target 'all' not remade because of errors.
>>> make[2]: Leaving directory
>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/libtest'
>>> Making all in unit
>>> make[2]: Entering directory
>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/unit'
>>> make[2]: Nothing to be done for 'all'.
>>> make[2]: Leaving directory
>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests/unit'
>>> make[2]: Entering directory
>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
>>> make[2]: Nothing to be done for 'all-am'.
>>> make[2]: Leaving directory
>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
>>> make[1]: *** [Makefile:513: all-recursive] Error 1
>>> make[1]: Target 'all' not remade because of errors.
>>> make[1]: Target 'quiet-test' not remade because of errors.
>>> make[1]: Leaving directory
>>> '/home/$USER/src/cygwin/curl/curl-7.71.1-2.x86_64/build/tests'
>>> make: *** [Makefile:1437: test] Error 2
>>
>> The attached patch should fix it.  I didn't take the trouble to write the patch
>> in a way that's suitable for sending upstream.  If you want to do that, you
>> could imitate what's done for libhostname.la a little earlier in the same
>> Makefile.am.  But I recommend that you first get curl 7.71.1-2 released before
>> spending time polishing the patch.
> 
> Thanks for the patches, pointers, and help understanding more of the autotools
> granular infrastructure.

You're welcome.  Glad I could help.

> I was able to polish the patch thanks to your pointers while waiting for the 32
> bit x86 build, rebuild and retest both arches last night, and upload and
> announce today.
> I will submit that upstream to the curl project developer on Github, now I know
> the project lives there.

Great.  I think it would be good if we maintainers did more of that (sending 
patches upstream).  I'm as guilty as anyone here.  Sometimes it just seems like 
too much trouble.

Ken