[ANNOUNCEMENT] Updated: curl 7.71.1-1

Brian Inglis Brian.Inglis@SystematicSw.ab.ca
Fri Aug 14 18:45:30 GMT 2020


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

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


More information about the Cygwin-apps mailing list