Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

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

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.
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.

-- 
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.]