[ANNOUNCEMENT] Updated: curl 7.71.1-1

[ANNOUNCEMENT] Updated: curl 7.71.1-1

[Brian Inglis]

The following packages have been uploaded to the Cygwin distribution:

* curl		7.71.1
* libcurl4	7.71.1
* libcurl-devel	7.71.1
* libcurl-doc	7.71.1

curl is a command line tool and library for transferring files
with URL syntax, supporting FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP,
TELNET, DICT, and FILE. curl supports SSL certificates, HTTP POST, HTTP
PUT, FTP uploading, HTTP form based upload, proxies, cookies,
user+password authentication (Basic, Digest, NTLM, Negotiate...), file
transfer resume, proxy tunneling and a busload of other useful tricks.

As there are multiple components and many changes each release please
read /usr/share/doc/curl/CHANGES after installation or see

    https://curl.haxx.se/changes.html

For more information about curl see the project home page:

    https://curl.haxx.se/

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[ASSI]

Brian Inglis writes:
> The following packages have been uploaded to the Cygwin distribution:
>
> * curl		7.71.1

Curl has dropped the dependency to libmetalink with this release, which
proably is a consequence of the newer SSL (the upstream Changelog is not
very clear there).  This was the only consumer of that library so maybe
it should be made obsolete going forward?


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Brian Inglis]

On 2020-07-20 11:58, ASSI wrote:
> Brian Inglis writes:
>> The following packages have been uploaded to the Cygwin distribution:
>> * curl		7.71.1

> Curl has dropped the dependency to libmetalink with this release, which
> probably is a consequence of the newer SSL (the upstream Changelog is not
> very clear there). This was the only consumer of that library so maybe
> it should be made obsolete going forward?

It may be used in wget, as that supports metalink, and is used by wget2, so
maybe I should pick up libmetalink if nothing else uses it?

Could someone perhaps check on the package build server with cygcheck or ldd for
any dependencies on cygmetalink-3.dll?

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

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Marco Atzeri]

On 10.08.2020 20:16, Brian Inglis wrote:
> On 2020-07-20 11:58, ASSI wrote:
>> Brian Inglis writes:
>>> The following packages have been uploaded to the Cygwin distribution:
>>> * curl		7.71.1
> 
>> Curl has dropped the dependency to libmetalink with this release, which
>> probably is a consequence of the newer SSL (the upstream Changelog is not
>> very clear there). This was the only consumer of that library so maybe
>> it should be made obsolete going forward?
> 
> It may be used in wget, as that supports metalink, and is used by wget2, so
> maybe I should pick up libmetalink if nothing else uses it?
> 
> Could someone perhaps check on the package build server with cygcheck or ldd for
> any dependencies on cygmetalink-3.dll?
> 

setup.ini reports only previous versions of curl depending from libmetalink3

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Adam Dinwoodie]

On Fri, 24 Jul 2020 at 13:56, Adam Dinwoodie wrote:
>
> Hi Brian,
>
> On Mon, 20 Jul 2020 at 13:53, Brian Inglis wrote:
> >
> > The following packages have been uploaded to the Cygwin distribution:
> >
> > * curl          7.71.1
> > * libcurl4      7.71.1
> > * libcurl-devel 7.71.1
> > * libcurl-doc   7.71.1
>
> This update appears to break parts of Git compilation that work using
> {curl,libcurl4,libcurl-devel}-7.66.0-1.
>
> Simple test case and error output below, setup.log and cygcheck.out
> attached; the setup.log includes a bunch of recent upgrades and
> downgrades while I isolated the problem and confirmed the STC.
>
> Test case: From a Bash shell, run: `curl
> https://git.kernel.org/pub/scm/git/git.git/snapshot/git-v2.27.0.tar.gz
> | tar -xz && cd git-v2.27.0 && make configure && ./configure
> --with-libpcre && make -j18 git-remote-http.exe`. This is a simplified
> version of the normal Cygport build process for the Cygwin Git
> packages.
>
> In the failing case, the `/configure` stage includes the following
> text: `configure: Setting CURL_LDFLAGS to '-lcurl -lnghttp2 -lidn2
> -lssh -lpsl -lssl -lcrypto -lldap -llber -lbrotlidec -lbrotlidec
> -lz'`; in the working case using -7.66.0-1, the corresponding line is
> just `configure: Setting CURL_LDFLAGS to '-lcurl'`.
>
> The error output at the end of the build in the failing case is as below:
>
> ```
>     LINK git-remote-http.exe
> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lnghttp2
> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lidn2
> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lssh
> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lpsl
> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lldap
> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -llber
> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lbrotlidec
> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lbrotlidec
> collect2: error: ld returned 1 exit status
> make: *** [Makefile:2488: git-remote-http.exe] Error 1
> ```
>
> For now I'm going to continue using the 7.66.0-1 packages; let me know
> if I can help with working out what's going wrong here at all.

Hi Brian,

Is there anything further I can do to help investigate this regression
in the Cygwin curl libraries?

Kind regards,

Adam

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Brian Inglis]

On 2020-08-09 12:28, Adam Dinwoodie wrote:
> On Fri, 24 Jul 2020 at 13:56, Adam Dinwoodie wrote:
>> On Mon, 20 Jul 2020 at 13:53, Brian Inglis wrote:
>>> The following packages have been uploaded to the Cygwin distribution:
>>> * curl          7.71.1
>>> * libcurl4      7.71.1
>>> * libcurl-devel 7.71.1
>>> * libcurl-doc   7.71.1

>> This update appears to break parts of Git compilation that work using
>> {curl,libcurl4,libcurl-devel}-7.66.0-1.
>>
>> Simple test case and error output below, setup.log and cygcheck.out
>> attached; the setup.log includes a bunch of recent upgrades and
>> downgrades while I isolated the problem and confirmed the STC.
>>
>> Test case: From a Bash shell, run: `curl
>> https://git.kernel.org/pub/scm/git/git.git/snapshot/git-v2.27.0.tar.gz
>> | tar -xz && cd git-v2.27.0 && make configure && ./configure
>> --with-libpcre && make -j18 git-remote-http.exe`. This is a simplified
>> version of the normal Cygport build process for the Cygwin Git
>> packages.
>>
>> In the failing case, the `/configure` stage includes the following
>> text: `configure: Setting CURL_LDFLAGS to '-lcurl -lnghttp2 -lidn2
>> -lssh -lpsl -lssl -lcrypto -lldap -llber -lbrotlidec -lbrotlidec
>> -lz'`; in the working case using -7.66.0-1, the corresponding line is
>> just `configure: Setting CURL_LDFLAGS to '-lcurl'`.
>>
>> The error output at the end of the build in the failing case is as below:
>>
>> ```
>>     LINK git-remote-http.exe
>> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>> cannot find -lnghttp2
>> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>> cannot find -lidn2
>> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>> cannot find -lssh
>> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>> cannot find -lpsl
>> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>> cannot find -lldap
>> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>> cannot find -llber
>> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>> cannot find -lbrotlidec
>> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>> cannot find -lbrotlidec
>> collect2: error: ld returned 1 exit status
>> make: *** [Makefile:2488: git-remote-http.exe] Error 1
>> ```
>>
>> For now I'm going to continue using the 7.66.0-1 packages; let me know
>> if I can help with working out what's going wrong here at all.

> Is there anything further I can do to help investigate this regression
> in the Cygwin curl libraries?

Your previous post never made it to me, either cygwin or cygwin-apps lists,
their archives, or mail-archives'.
Please check the archives and your email and repost.

Meanwhile, that info likely comes from:

$ tail -vn15 /lib/pkgconfig/libcurl.pc
==> /lib/pkgconfig/libcurl.pc <==
#
prefix=/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib
includedir=${prefix}/include
supported_protocols="DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS LDAP LDAPS
POP3 POP3S RTSP SCP SFTP SMB SMBS SMTP SMTPS TELNET TFTP"
supported_features="SSL IPv6 UnixSockets libz brotli AsynchDNS IDN PSL NTLM
NTLM_WB TLS-SRP HTTP2 HTTPS-proxy"

Name: libcurl
URL: https://curl.haxx.se/
Description: Library to transfer files with ftp, http, etc.
Version: 7.71.1
Libs: -L${libdir} -lcurl
Libs.private: -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto -lldap -llber
-lbrotlidec -lbrotlidec -lz
Cflags: -I${includedir}

it looks like your git build should be using Libs for dynamic builds and adding
Libs.private for static builds, so please check whether and how that is used,
and whether you have at least the runtime libs installed, and also the -devel
packages if you are building statically.
Static builds are not uncommon for test versions of package modules, as that
avoids issues with having to install package or dependency dynamic libraries
that may not yet be ready for prime time.

I have never had any problems with packages using pkgconf/-config and never had
to look into it, so anyone with more knowledge and experience of issues there
should feel free to contribute.

Trying to build with cygport:

- it died silently as I did not have bash-completion-devel installed: could you
please perhaps move that pkg-config line into src-compile, so that cygport can
at least run, check, and complain about missing dependencies?

- it complains that perl(DBD::SQLite) perl(IO::Pty) are not installed - how do
these and your other perl module dependencies map to Cygwin packages?
I also mean that in general - how can I map a perl module to a perl package and
vice versa - for future info?

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

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Brian Inglis]

On 2020-08-09 15:48, Brian Inglis wrote:
> On 2020-08-09 12:28, Adam Dinwoodie wrote:
>> On Fri, 24 Jul 2020 at 13:56, Adam Dinwoodie wrote:
>>> On Mon, 20 Jul 2020 at 13:53, Brian Inglis wrote:
>>>> The following packages have been uploaded to the Cygwin distribution:
>>>> * curl          7.71.1
>>>> * libcurl4      7.71.1
>>>> * libcurl-devel 7.71.1
>>>> * libcurl-doc   7.71.1
> 
>>> This update appears to break parts of Git compilation that work using
>>> {curl,libcurl4,libcurl-devel}-7.66.0-1.
>>>
>>> Simple test case and error output below, setup.log and cygcheck.out
>>> attached; the setup.log includes a bunch of recent upgrades and
>>> downgrades while I isolated the problem and confirmed the STC.
>>>
>>> Test case: From a Bash shell, run: `curl
>>> https://git.kernel.org/pub/scm/git/git.git/snapshot/git-v2.27.0.tar.gz
>>> | tar -xz && cd git-v2.27.0 && make configure && ./configure
>>> --with-libpcre && make -j18 git-remote-http.exe`. This is a simplified
>>> version of the normal Cygport build process for the Cygwin Git
>>> packages.
>>>
>>> In the failing case, the `/configure` stage includes the following
>>> text: `configure: Setting CURL_LDFLAGS to '-lcurl -lnghttp2 -lidn2
>>> -lssh -lpsl -lssl -lcrypto -lldap -llber -lbrotlidec -lbrotlidec
>>> -lz'`; in the working case using -7.66.0-1, the corresponding line is
>>> just `configure: Setting CURL_LDFLAGS to '-lcurl'`.
>>>
>>> The error output at the end of the build in the failing case is as below:
>>>
>>> ```
>>>     LINK git-remote-http.exe
>>> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>>> cannot find -lnghttp2
>>> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>>> cannot find -lidn2
>>> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>>> cannot find -lssh
>>> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>>> cannot find -lpsl
>>> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>>> cannot find -lldap
>>> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>>> cannot find -llber
>>> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>>> cannot find -lbrotlidec
>>> /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld:
>>> cannot find -lbrotlidec
>>> collect2: error: ld returned 1 exit status
>>> make: *** [Makefile:2488: git-remote-http.exe] Error 1
>>> ```
>>>
>>> For now I'm going to continue using the 7.66.0-1 packages; let me know
>>> if I can help with working out what's going wrong here at all.
> 
>> Is there anything further I can do to help investigate this regression
>> in the Cygwin curl libraries?
> 
> Your previous post never made it to me, either cygwin or cygwin-apps lists,
> their archives, or mail-archives'.
> Please check the archives and your email and repost.
> 
> Meanwhile, that info likely comes from:
> 
> $ tail -vn15 /lib/pkgconfig/libcurl.pc
> ==> /lib/pkgconfig/libcurl.pc <==
> #
> prefix=/usr
> exec_prefix=/usr
> libdir=${exec_prefix}/lib
> includedir=${prefix}/include
> supported_protocols="DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS LDAP LDAPS
> POP3 POP3S RTSP SCP SFTP SMB SMBS SMTP SMTPS TELNET TFTP"
> supported_features="SSL IPv6 UnixSockets libz brotli AsynchDNS IDN PSL NTLM
> NTLM_WB TLS-SRP HTTP2 HTTPS-proxy"
> 
> Name: libcurl
> URL: https://curl.haxx.se/
> Description: Library to transfer files with ftp, http, etc.
> Version: 7.71.1
> Libs: -L${libdir} -lcurl
> Libs.private: -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto -lldap -llber
> -lbrotlidec -lbrotlidec -lz
> Cflags: -I${includedir}
> 
> it looks like your git build should be using Libs for dynamic builds and adding
> Libs.private for static builds, so please check whether and how that is used,
> and whether you have at least the runtime libs installed, and also the -devel
> packages if you are building statically.
> Static builds are not uncommon for test versions of package modules, as that
> avoids issues with having to install package or dependency dynamic libraries
> that may not yet be ready for prime time.
> 
> I have never had any problems with packages using pkgconf/-config and never had
> to look into it, so anyone with more knowledge and experience of issues there
> should feel free to contribute.
> 
> Trying to build with cygport:
> 
> - it died silently as I did not have bash-completion-devel installed: could you
> please perhaps move that pkg-config line into src-compile, so that cygport can
> at least run, check, and complain about missing dependencies?
> 
> - it complains that perl(DBD::SQLite) perl(IO::Pty) are not installed - how do
> these and your other perl module dependencies map to Cygwin packages?
> I also mean that in general - how can I map a perl module to a perl package and
> vice versa - for future info?

Build ran without problems other than above complaint, and some tests were
skipped especially svn, cvs, p4, gitweb, those requiring explicit env settings,
and some subtests failed:

...
    AR libgit.a
    LINK git-bugreport.exe
    LINK git-credential-store.exe
    LINK git-daemon.exe
    LINK git-fast-import.exe
    LINK git-http-backend.exe
    LINK git-remote-testsvn.exe
    LINK git-imap-send.exe
    LINK git-sh-i18n--envsubst.exe
    LINK git-shell.exe
    LINK git-http-fetch.exe
    LINK git-credential-cache.exe
    LINK git-http-push.exe
    LINK git-credential-cache--daemon.exe
    LINK git-remote-http.exe
    LINK git.exe
...
Test Summary Report
-------------------
t3070-wildmatch.sh  (Wstat: 256 Tests: 1890 Failed: 44)
  Failed tests:  114, 116, 118, 120, 674, 676, 678, 680
                734, 736, 738, 740, 744, 746, 748, 750
                954, 956, 958, 960, 964, 966, 968, 970
                974, 976, 978, 980, 1284, 1286, 1288, 1290
                1374, 1376, 1378, 1380, 1414, 1416, 1418
                1420, 1424, 1426, 1428, 1430
  Non-zero exit status: 1
t5500-fetch-pack.sh  (Wstat: 256 Tests: 372 Failed: 12)
  Failed tests:  145, 148, 164-165, 242, 245, 261-262, 339
                342, 358-359
  Non-zero exit status: 1
t5580-unc-paths.sh  (Wstat: 256 Tests: 8 Failed: 3)
  Failed tests:  4, 6, 8
  Non-zero exit status: 1
t5601-clone.sh  (Wstat: 256 Tests: 104 Failed: 4)
  Failed tests:  62-64, 66
  Non-zero exit status: 1
t7815-grep-binary.sh  (Wstat: 0 Tests: 22 Failed: 0)
  TODO passed:   12
Files=908, Tests=22240, 17749 wallclock secs
        (12.25 usr 32.41 sys + 6979.47 cusr 28075.98 csys = 35100.10 CPU)
Result: FAIL
make[1]: *** [Makefile:52: prove] Error 1
make[1]: Target all not remade because of errors.
make[1]: Leaving directory
/mnt/c/Users/bwi/src/cygwin/git/git-2.28.0-1.x86_64/build/t
make: *** [Makefile:2767: 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.]

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Ken Brown]

On 8/9/2020 5:48 PM, Brian Inglis wrote:
> On 2020-08-09 12:28, Adam Dinwoodie wrote:
>> On Fri, 24 Jul 2020 at 13:56, Adam Dinwoodie wrote:
>>> In the failing case, the `/configure` stage includes the following
>>> text: `configure: Setting CURL_LDFLAGS to '-lcurl -lnghttp2 -lidn2
>>> -lssh -lpsl -lssl -lcrypto -lldap -llber -lbrotlidec -lbrotlidec
>>> -lz'`; in the working case using -7.66.0-1, the corresponding line is
>>> just `configure: Setting CURL_LDFLAGS to '-lcurl'`.
[...]
> Meanwhile, that info likely comes from:
> 
> $ tail -vn15 /lib/pkgconfig/libcurl.pc
> ==> /lib/pkgconfig/libcurl.pc <==
> #
> prefix=/usr
> exec_prefix=/usr
> libdir=${exec_prefix}/lib
> includedir=${prefix}/include
> supported_protocols="DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS LDAP LDAPS
> POP3 POP3S RTSP SCP SFTP SMB SMBS SMTP SMTPS TELNET TFTP"
> supported_features="SSL IPv6 UnixSockets libz brotli AsynchDNS IDN PSL NTLM
> NTLM_WB TLS-SRP HTTP2 HTTPS-proxy"
> 
> Name: libcurl
> URL: https://curl.haxx.se/
> Description: Library to transfer files with ftp, http, etc.
> Version: 7.71.1
> Libs: -L${libdir} -lcurl
> Libs.private: -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto -lldap -llber
> -lbrotlidec -lbrotlidec -lz
> Cflags: -I${includedir}
> 
> it looks like your git build should be using Libs for dynamic builds and adding
> Libs.private for static builds

If you look at configure.ac in the git sources, you'll see that it uses 
curl-config, not pkg-config.  The former reports:

$ curl-config --libs
-lcurl -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto -lldap -llber -lbrotlidec 
-lbrotlidec -lz

Yaakov's build of earlier versions of curl used a patch 7.33.0-libdeps.patch to 
prevent the unnecessary libs from being listed.  He even had a comment at the 
beginning of the patch, explaining the reason for it: "These are needed only for 
static linking, but we build with --disable-static".

Ken

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Brian Inglis]

On 2020-08-10 08:52, Ken Brown via Cygwin wrote:
> On 8/9/2020 5:48 PM, Brian Inglis wrote:
>> On 2020-08-09 12:28, Adam Dinwoodie wrote:
>>> On Fri, 24 Jul 2020 at 13:56, Adam Dinwoodie wrote:
>>>> In the failing case, the `/configure` stage includes the following
>>>> text: `configure: Setting CURL_LDFLAGS to '-lcurl -lnghttp2 -lidn2
>>>> -lssh -lpsl -lssl -lcrypto -lldap -llber -lbrotlidec -lbrotlidec
>>>> -lz'`; in the working case using -7.66.0-1, the corresponding line is
>>>> just `configure: Setting CURL_LDFLAGS to '-lcurl'`.
> [...]
>> Meanwhile, that info likely comes from:
>>
>> $ tail -vn15 /lib/pkgconfig/libcurl.pc
>> ==> /lib/pkgconfig/libcurl.pc <==
>> #
>> prefix=/usr
>> exec_prefix=/usr
>> libdir=${exec_prefix}/lib
>> includedir=${prefix}/include
>> supported_protocols="DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS LDAP LDAPS
>> POP3 POP3S RTSP SCP SFTP SMB SMBS SMTP SMTPS TELNET TFTP"
>> supported_features="SSL IPv6 UnixSockets libz brotli AsynchDNS IDN PSL NTLM
>> NTLM_WB TLS-SRP HTTP2 HTTPS-proxy"
>>
>> Name: libcurl
>> URL: https://curl.haxx.se/
>> Description: Library to transfer files with ftp, http, etc.
>> Version: 7.71.1
>> Libs: -L${libdir} -lcurl
>> Libs.private: -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto -lldap -llber
>> -lbrotlidec -lbrotlidec -lz
>> Cflags: -I${includedir}
>>
>> it looks like your git build should be using Libs for dynamic builds and adding
>> Libs.private for static builds

> If you look at configure.ac in the git sources, you'll see that it uses
> curl-config, not pkg-config.  The former reports:
> 
> $ curl-config --libs
> -lcurl -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto -lldap -llber -lbrotlidec
> -lbrotlidec -lz
> 
> Yaakov's build of earlier versions of curl used a patch 7.33.0-libdeps.patch to
> prevent the unnecessary libs from being listed.  He even had a comment at the
> beginning of the patch, explaining the reason for it: "These are needed only for
> static linking, but we build with --disable-static".

I try to avoid looking at autotools plumbing if I can possibly avoid it! ;^>
Someone cleaned up the approach used, as the patch did not apply and was dropped.
If you look at my later post, cygport git build and tests worked for me with no
problems other than at first missing some package build dependencies and in the
end I was still missing a couple of perl module dependencies I cannot decode.

I am waiting to hear back from the git maintainer when he has time.

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

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Ken Brown]

[-- Attachment #1: Type: text/plain, Size: 2982 bytes --]

On 8/10/2020 1:33 PM, Brian Inglis wrote:
> On 2020-08-10 08:52, Ken Brown via Cygwin wrote:
>> On 8/9/2020 5:48 PM, Brian Inglis wrote:
>>> On 2020-08-09 12:28, Adam Dinwoodie wrote:
>>>> On Fri, 24 Jul 2020 at 13:56, Adam Dinwoodie wrote:
>>>>> In the failing case, the `/configure` stage includes the following
>>>>> text: `configure: Setting CURL_LDFLAGS to '-lcurl -lnghttp2 -lidn2
>>>>> -lssh -lpsl -lssl -lcrypto -lldap -llber -lbrotlidec -lbrotlidec
>>>>> -lz'`; in the working case using -7.66.0-1, the corresponding line is
>>>>> just `configure: Setting CURL_LDFLAGS to '-lcurl'`.
>> [...]
>>> Meanwhile, that info likely comes from:
>>>
>>> $ tail -vn15 /lib/pkgconfig/libcurl.pc
>>> ==> /lib/pkgconfig/libcurl.pc <==
>>> #
>>> prefix=/usr
>>> exec_prefix=/usr
>>> libdir=${exec_prefix}/lib
>>> includedir=${prefix}/include
>>> supported_protocols="DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS LDAP LDAPS
>>> POP3 POP3S RTSP SCP SFTP SMB SMBS SMTP SMTPS TELNET TFTP"
>>> supported_features="SSL IPv6 UnixSockets libz brotli AsynchDNS IDN PSL NTLM
>>> NTLM_WB TLS-SRP HTTP2 HTTPS-proxy"
>>>
>>> Name: libcurl
>>> URL: https://curl.haxx.se/
>>> Description: Library to transfer files with ftp, http, etc.
>>> Version: 7.71.1
>>> Libs: -L${libdir} -lcurl
>>> Libs.private: -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto -lldap -llber
>>> -lbrotlidec -lbrotlidec -lz
>>> Cflags: -I${includedir}
>>>
>>> it looks like your git build should be using Libs for dynamic builds and adding
>>> Libs.private for static builds
> 
>> If you look at configure.ac in the git sources, you'll see that it uses
>> curl-config, not pkg-config.  The former reports:
>>
>> $ curl-config --libs
>> -lcurl -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto -lldap -llber -lbrotlidec
>> -lbrotlidec -lz
>>
>> Yaakov's build of earlier versions of curl used a patch 7.33.0-libdeps.patch to
>> prevent the unnecessary libs from being listed.  He even had a comment at the
>> beginning of the patch, explaining the reason for it: "These are needed only for
>> static linking, but we build with --disable-static".
> 
> I try to avoid looking at autotools plumbing if I can possibly avoid it! ;^>
> Someone cleaned up the approach used, as the patch did not apply and was dropped.

My point is that the patch shouldn't have been dropped.  It should have been 
modified to apply to the updated sources.  (I've done this.  See the attached.) 
As Yaakov wrote, the patch is needed to prevent 'curl-config --libs' from 
including libs that are only needed for static linking.

With the modified patch applied, curl-config gives the expected result:

$ curl-config --libs
-lcurl

> If you look at my later post, cygport git build and tests worked for me with no
> problems other than at first missing some package build dependencies

Those were not really build dependencies.  They only appeared to be needed 
because 'curl-config --libs' erroneously included libs that are only needed for 
static linking.

Ken

[-- Attachment #2: 7.71.1-libdeps.patch --]
[-- Type: text/plain, Size: 994 bytes --]

These are needed only for static linking, but we build with --disable-static

--- origsrc/curl-7.71.1/curl-config.in	2020-06-27 18:03:53.000000000 -0400
+++ src/curl-7.71.1/curl-config.in	2020-08-10 14:31:22.719684300 -0400
@@ -160,7 +160,7 @@ while test $# -gt 0; do
         else
            CURLLIBDIR=""
         fi
-        if test "X@ENABLE_SHARED@" = "Xno" -o "X@REQUIRE_LIB_DEPS@" = "Xyes"; then
+        if test "X@ENABLE_SHARED@" = "Xno" -o "X@REQUIRE_LIB_DEPS@" = "Xnothanks"; then
           echo ${CURLLIBDIR}-lcurl @LIBCURL_LIBS@
         else
           echo ${CURLLIBDIR}-lcurl
--- origsrc/curl-7.71.1/libcurl.pc.in	2020-06-27 18:03:53.000000000 -0400
+++ src/curl-7.71.1/libcurl.pc.in	2020-08-10 14:33:36.069651700 -0400
@@ -35,5 +35,4 @@ URL: https://curl.haxx.se/
 Description: Library to transfer files with ftp, http, etc.
 Version: @CURLVERSION@
 Libs: -L${libdir} -lcurl @LIBCURL_NO_SHARED@
-Libs.private: @LIBCURL_LIBS@
 Cflags: -I${includedir} @CPPFLAG_CURL_STATICLIB@

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Adam Dinwoodie]

On Sunday 09 August 2020 at 03:48 pm -0600, Brian Inglis wrote:
> Your previous post never made it to me, either cygwin or cygwin-apps lists,
> their archives, or mail-archives'.
> Please check the archives and your email and repost.

Huh.  There was absolutely no indication from my end that anything
hadn't sent.  No idea what went wrong there.

> <snip>
>
> Trying to build with cygport:
>
> - it died silently as I did not have bash-completion-devel installed: could you
> please perhaps move that pkg-config line into src-compile, so that cygport can
> at least run, check, and complain about missing dependencies?

Good shout; it has never bothered me, but it's clearly a sensible change
to make.  I'll do that for the next release.

> - it complains that perl(DBD::SQLite) perl(IO::Pty) are not installed - how do
> these and your other perl module dependencies map to Cygwin packages?
> I also mean that in general - how can I map a perl module to a perl package and
> vice versa - for future info?

Honestly, I've no idea; I don't think there's any canonical conversion.
I mostly have the mapping between Perl modules and their corresponding
Cygwin packages memorised at this point, as they're mostly fairly
obvious if you're looking at the list of packages in the Cygwin
installer.

In theory you could have looked at my cygport.out to see what packages I
had installed, but that would have required my cygport.out that was
attached to the original email that was evidently eaten by a grue.

On Sunday 09 August 2020 at 09:32 pm -0600, Brian Inglis wrote:
> Build ran without problems other than above complaint, and some tests were
> skipped especially svn, cvs, p4, gitweb, those requiring explicit env settings,
> and some subtests failed:
>
> <snip>
> Test Summary Report
> -------------------
> t3070-wildmatch.sh  (Wstat: 256 Tests: 1890 Failed: 44)
>   Failed tests:  114, 116, 118, 120, 674, 676, 678, 680
>                 734, 736, 738, 740, 744, 746, 748, 750
>                 954, 956, 958, 960, 964, 966, 968, 970
>                 974, 976, 978, 980, 1284, 1286, 1288, 1290
>                 1374, 1376, 1378, 1380, 1414, 1416, 1418
>                 1420, 1424, 1426, 1428, 1430
>   Non-zero exit status: 1
> t5500-fetch-pack.sh  (Wstat: 256 Tests: 372 Failed: 12)
>   Failed tests:  145, 148, 164-165, 242, 245, 261-262, 339
>                 342, 358-359
>   Non-zero exit status: 1
> t5580-unc-paths.sh  (Wstat: 256 Tests: 8 Failed: 3)
>   Failed tests:  4, 6, 8
>   Non-zero exit status: 1
> t5601-clone.sh  (Wstat: 256 Tests: 104 Failed: 4)
>   Failed tests:  62-64, 66
>   Non-zero exit status: 1
> t7815-grep-binary.sh  (Wstat: 0 Tests: 22 Failed: 0)
>   TODO passed:   12
> Files=908, Tests=22240, 17749 wallclock secs
>         (12.25 usr 32.41 sys + 6979.47 cusr 28075.98 csys = 35100.10 CPU)
> Result: FAIL
> make[1]: *** [Makefile:52: prove] Error 1
> make[1]: Target all not remade because of errors.
> make[1]: Leaving directory
> /mnt/c/Users/bwi/src/cygwin/git/git-2.28.0-1.x86_64/build/t
> make: *** [Makefile:2767: test] Error 2

That's the currently expected test output for 64-bit Cygwin; cleaning it
up is on my to-do list.

git-remote-http is going to be one of the tests that requires either
gitweb or specific environment settings, because it's fundamentally
about running an HTTP interface, and Git's test scripts don't want to
set one of those up for you silently.

On Monday 10 August 2020 at 03:14 pm -0400, Ken Brown via Cygwin wrote:
> On 8/10/2020 1:33 PM, Brian Inglis wrote:
> > I try to avoid looking at autotools plumbing if I can possibly avoid it! ;^>
> > Someone cleaned up the approach used, as the patch did not apply and was dropped.

Likewise!  I was somewhat hoping someone else would be able to work out
what was going wrong, and it looks like Ken has achieved that.

> My point is that the patch shouldn't have been dropped.  It should have been
> modified to apply to the updated sources.  (I've done this.  See the
> attached.) As Yaakov wrote, the patch is needed to prevent 'curl-config
> --libs' from including libs that are only needed for static linking.
>
> With the modified patch applied, curl-config gives the expected result:
>
> $ curl-config --libs
> -lcurl
>
> > If you look at my later post, cygport git build and tests worked for me with no
> > problems other than at first missing some package build dependencies
>
> Those were not really build dependencies.  They only appeared to be needed
> because 'curl-config --libs' erroneously included libs that are only needed
> for static linking.

I've not rebuilt with Ken's patch, but given the behaviour he describes,
the patch looks sensible to me.  Brian, let me know if you reckon
there's value in me rebuilding Curl with this patch and trying to
rebuild Git, or if you're okay to incorporate this patch into a Curl
rebuild now?

Thanks all!

Adam

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Brian Inglis]

[-- Attachment #1: Type: text/plain, Size: 5281 bytes --]

On 2020-08-10 13:14, Ken Brown via Cygwin wrote:
> On 8/10/2020 1:33 PM, Brian Inglis wrote:
>> On 2020-08-10 08:52, Ken Brown via Cygwin wrote:
>>> On 8/9/2020 5:48 PM, Brian Inglis wrote:
>>>> On 2020-08-09 12:28, Adam Dinwoodie wrote:
>>>>> On Fri, 24 Jul 2020 at 13:56, Adam Dinwoodie wrote:
>>>>>> In the failing case, the `/configure` stage includes the following
>>>>>> text: `configure: Setting CURL_LDFLAGS to '-lcurl -lnghttp2 -lidn2
>>>>>> -lssh -lpsl -lssl -lcrypto -lldap -llber -lbrotlidec -lbrotlidec
>>>>>> -lz'`; in the working case using -7.66.0-1, the corresponding line is
>>>>>> just `configure: Setting CURL_LDFLAGS to '-lcurl'`.
>>> [...]
>>>> Meanwhile, that info likely comes from:
>>>>
>>>> $ tail -vn15 /lib/pkgconfig/libcurl.pc
>>>> ==> /lib/pkgconfig/libcurl.pc <==
>>>> #
>>>> prefix=/usr
>>>> exec_prefix=/usr
>>>> libdir=${exec_prefix}/lib
>>>> includedir=${prefix}/include
>>>> supported_protocols="DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS LDAP LDAPS
>>>> POP3 POP3S RTSP SCP SFTP SMB SMBS SMTP SMTPS TELNET TFTP"
>>>> supported_features="SSL IPv6 UnixSockets libz brotli AsynchDNS IDN PSL NTLM
>>>> NTLM_WB TLS-SRP HTTP2 HTTPS-proxy"
>>>>
>>>> Name: libcurl
>>>> URL: https://curl.haxx.se/
>>>> Description: Library to transfer files with ftp, http, etc.
>>>> Version: 7.71.1
>>>> Libs: -L${libdir} -lcurl
>>>> Libs.private: -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto -lldap -llber
>>>> -lbrotlidec -lbrotlidec -lz
>>>> Cflags: -I${includedir}
>>>>
>>>> it looks like your git build should be using Libs for dynamic builds and adding
>>>> Libs.private for static builds
>>
>>> If you look at configure.ac in the git sources, you'll see that it uses
>>> curl-config, not pkg-config.  The former reports:
>>>
>>> $ curl-config --libs
>>> -lcurl -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto -lldap -llber -lbrotlidec
>>> -lbrotlidec -lz
>>>
>>> Yaakov's build of earlier versions of curl used a patch 7.33.0-libdeps.patch to
>>> prevent the unnecessary libs from being listed.  He even had a comment at the
>>> beginning of the patch, explaining the reason for it: "These are needed only for
>>> static linking, but we build with --disable-static".
>>
>> I try to avoid looking at autotools plumbing if I can possibly avoid it! ;^>
>> Someone cleaned up the approach used, as the patch did not apply and was dropped.
> 
> My point is that the patch shouldn't have been dropped.  It should have been
> modified to apply to the updated sources.  (I've done this.  See the attached.)
> As Yaakov wrote, the patch is needed to prevent 'curl-config --libs' from
> including libs that are only needed for static linking.
> 
> With the modified patch applied, curl-config gives the expected result:
> 
> $ curl-config --libs
> -lcurl
> 
>> If you look at my later post, cygport git build and tests worked for me with no
>> problems other than at first missing some package build dependencies
> 
> Those were not really build dependencies.  They only appeared to be needed
> because 'curl-config --libs' erroneously included libs that are only needed for
> static linking.

Your patch seems to reproduce exactly what is currently distributed in the
libcurl-devel package:

$ tail -n7 /lib/pkgconfig/libcurl.pc
Name: libcurl
URL: https://curl.haxx.se/
Description: Library to transfer files with ftp, http, etc.
Version: 7.71.1
Libs: -L${libdir} -lcurl
Libs.private: -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto -lldap -llber
-lbrotlidec -lbrotlidec -lz
Cflags: -I${includedir}

and from what I can see, picked up and used in my vanilla cygport git build from
the vanilla distributed src package:

$ for exe in *.exe */*.exe; do ldd $exe | fgrep -q cygcurl && cygcheck ./$exe &&
echo; done > ~/git-curl.log

[see attached]

Perhaps I am misunderstanding: I was addressing the OP build issue; are you
perhaps concerned solely with the correct operation of curl-config?

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 can provide any more insight on the autotools generation of curl-config,
I can add that to the upstream bug report.

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

[-- Attachment #2: git-curl.log --]
[-- Type: text/plain, Size: 8553 bytes --]

$HOME\src\cygwin\git\git-2.28.0-1.x86_64\inst\usr\libexec\git-core\git-http-fetch.exe
  C:\...\cygwin64\bin\cygcurl-4.dll
    C:\...\cygwin64\bin\cygbrotlidec-1.dll
      C:\...\cygwin64\bin\cygwin1.dll
        C:\Windows\system32\KERNEL32.dll
          C:\Windows\system32\ntdll.dll
          C:\Windows\system32\KERNELBASE.dll
      C:\...\cygwin64\bin\cygbrotlicommon-1.dll
    C:\...\cygwin64\bin\cygcrypto-1.1.dll
      C:\...\cygwin64\bin\cygz.dll
    C:\...\cygwin64\bin\cygidn2-0.dll
      C:\...\cygwin64\bin\cygiconv-2.dll
      C:\...\cygwin64\bin\cygintl-8.dll
      C:\...\cygwin64\bin\cygunistring-2.dll
    C:\...\cygwin64\bin\cyglber-2-4-2.dll
    C:\...\cygwin64\bin\cygldap-2-4-2.dll
      C:\...\cygwin64\bin\cygsasl2-3.dll
      C:\...\cygwin64\bin\cygssl-1.1.dll
    C:\...\cygwin64\bin\cygnghttp2-14.dll
    C:\...\cygwin64\bin\cygpsl-5.dll
    C:\...\cygwin64\bin\cygssh-4.dll
      C:\...\cygwin64\bin\cyggcc_s-seh-1.dll
      C:\...\cygwin64\bin\cyggssapi_krb5-2.dll
        C:\...\cygwin64\bin\cygk5crypto-3.dll
          C:\...\cygwin64\bin\cygkrb5support-0.dll
        C:\...\cygwin64\bin\cygkrb5-3.dll
          C:\...\cygwin64\bin\cygcom_err-2.dll
  C:\...\cygwin64\bin\cygpcre2-8-0.dll

$HOME\src\cygwin\git\git-2.28.0-1.x86_64\inst\usr\libexec\git-core\git-http-push.exe
  C:\...\cygwin64\bin\cygcurl-4.dll
    C:\...\cygwin64\bin\cygbrotlidec-1.dll
      C:\...\cygwin64\bin\cygwin1.dll
        C:\Windows\system32\KERNEL32.dll
          C:\Windows\system32\ntdll.dll
          C:\Windows\system32\KERNELBASE.dll
      C:\...\cygwin64\bin\cygbrotlicommon-1.dll
    C:\...\cygwin64\bin\cygcrypto-1.1.dll
      C:\...\cygwin64\bin\cygz.dll
    C:\...\cygwin64\bin\cygidn2-0.dll
      C:\...\cygwin64\bin\cygiconv-2.dll
      C:\...\cygwin64\bin\cygintl-8.dll
      C:\...\cygwin64\bin\cygunistring-2.dll
    C:\...\cygwin64\bin\cyglber-2-4-2.dll
    C:\...\cygwin64\bin\cygldap-2-4-2.dll
      C:\...\cygwin64\bin\cygsasl2-3.dll
      C:\...\cygwin64\bin\cygssl-1.1.dll
    C:\...\cygwin64\bin\cygnghttp2-14.dll
    C:\...\cygwin64\bin\cygpsl-5.dll
    C:\...\cygwin64\bin\cygssh-4.dll
      C:\...\cygwin64\bin\cyggcc_s-seh-1.dll
      C:\...\cygwin64\bin\cyggssapi_krb5-2.dll
        C:\...\cygwin64\bin\cygk5crypto-3.dll
          C:\...\cygwin64\bin\cygkrb5support-0.dll
        C:\...\cygwin64\bin\cygkrb5-3.dll
          C:\...\cygwin64\bin\cygcom_err-2.dll
  C:\...\cygwin64\bin\cygexpat-1.dll
  C:\...\cygwin64\bin\cygpcre2-8-0.dll

$HOME\src\cygwin\git\git-2.28.0-1.x86_64\inst\usr\libexec\git-core\git-imap-send.exe
  C:\...\cygwin64\bin\cygcrypto-1.1.dll
    C:\...\cygwin64\bin\cygwin1.dll
      C:\Windows\system32\KERNEL32.dll
        C:\Windows\system32\ntdll.dll
        C:\Windows\system32\KERNELBASE.dll
    C:\...\cygwin64\bin\cygz.dll
  C:\...\cygwin64\bin\cygcurl-4.dll
    C:\...\cygwin64\bin\cygbrotlidec-1.dll
      C:\...\cygwin64\bin\cygbrotlicommon-1.dll
    C:\...\cygwin64\bin\cygidn2-0.dll
      C:\...\cygwin64\bin\cygiconv-2.dll
      C:\...\cygwin64\bin\cygintl-8.dll
      C:\...\cygwin64\bin\cygunistring-2.dll
    C:\...\cygwin64\bin\cyglber-2-4-2.dll
    C:\...\cygwin64\bin\cygldap-2-4-2.dll
      C:\...\cygwin64\bin\cygsasl2-3.dll
      C:\...\cygwin64\bin\cygssl-1.1.dll
    C:\...\cygwin64\bin\cygnghttp2-14.dll
    C:\...\cygwin64\bin\cygpsl-5.dll
    C:\...\cygwin64\bin\cygssh-4.dll
      C:\...\cygwin64\bin\cyggcc_s-seh-1.dll
      C:\...\cygwin64\bin\cyggssapi_krb5-2.dll
        C:\...\cygwin64\bin\cygk5crypto-3.dll
          C:\...\cygwin64\bin\cygkrb5support-0.dll
        C:\...\cygwin64\bin\cygkrb5-3.dll
          C:\...\cygwin64\bin\cygcom_err-2.dll
  C:\...\cygwin64\bin\cygpcre2-8-0.dll

$HOME\src\cygwin\git\git-2.28.0-1.x86_64\inst\usr\libexec\git-core\git-remote-ftp.exe
  C:\...\cygwin64\bin\cygcurl-4.dll
    C:\...\cygwin64\bin\cygbrotlidec-1.dll
      C:\...\cygwin64\bin\cygwin1.dll
        C:\Windows\system32\KERNEL32.dll
          C:\Windows\system32\ntdll.dll
          C:\Windows\system32\KERNELBASE.dll
      C:\...\cygwin64\bin\cygbrotlicommon-1.dll
    C:\...\cygwin64\bin\cygcrypto-1.1.dll
      C:\...\cygwin64\bin\cygz.dll
    C:\...\cygwin64\bin\cygidn2-0.dll
      C:\...\cygwin64\bin\cygiconv-2.dll
      C:\...\cygwin64\bin\cygintl-8.dll
      C:\...\cygwin64\bin\cygunistring-2.dll
    C:\...\cygwin64\bin\cyglber-2-4-2.dll
    C:\...\cygwin64\bin\cygldap-2-4-2.dll
      C:\...\cygwin64\bin\cygsasl2-3.dll
      C:\...\cygwin64\bin\cygssl-1.1.dll
    C:\...\cygwin64\bin\cygnghttp2-14.dll
    C:\...\cygwin64\bin\cygpsl-5.dll
    C:\...\cygwin64\bin\cygssh-4.dll
      C:\...\cygwin64\bin\cyggcc_s-seh-1.dll
      C:\...\cygwin64\bin\cyggssapi_krb5-2.dll
        C:\...\cygwin64\bin\cygk5crypto-3.dll
          C:\...\cygwin64\bin\cygkrb5support-0.dll
        C:\...\cygwin64\bin\cygkrb5-3.dll
          C:\...\cygwin64\bin\cygcom_err-2.dll
  C:\...\cygwin64\bin\cygpcre2-8-0.dll

$HOME\src\cygwin\git\git-2.28.0-1.x86_64\inst\usr\libexec\git-core\git-remote-ftps.exe
  C:\...\cygwin64\bin\cygcurl-4.dll
    C:\...\cygwin64\bin\cygbrotlidec-1.dll
      C:\...\cygwin64\bin\cygwin1.dll
        C:\Windows\system32\KERNEL32.dll
          C:\Windows\system32\ntdll.dll
          C:\Windows\system32\KERNELBASE.dll
      C:\...\cygwin64\bin\cygbrotlicommon-1.dll
    C:\...\cygwin64\bin\cygcrypto-1.1.dll
      C:\...\cygwin64\bin\cygz.dll
    C:\...\cygwin64\bin\cygidn2-0.dll
      C:\...\cygwin64\bin\cygiconv-2.dll
      C:\...\cygwin64\bin\cygintl-8.dll
      C:\...\cygwin64\bin\cygunistring-2.dll
    C:\...\cygwin64\bin\cyglber-2-4-2.dll
    C:\...\cygwin64\bin\cygldap-2-4-2.dll
      C:\...\cygwin64\bin\cygsasl2-3.dll
      C:\...\cygwin64\bin\cygssl-1.1.dll
    C:\...\cygwin64\bin\cygnghttp2-14.dll
    C:\...\cygwin64\bin\cygpsl-5.dll
    C:\...\cygwin64\bin\cygssh-4.dll
      C:\...\cygwin64\bin\cyggcc_s-seh-1.dll
      C:\...\cygwin64\bin\cyggssapi_krb5-2.dll
        C:\...\cygwin64\bin\cygk5crypto-3.dll
          C:\...\cygwin64\bin\cygkrb5support-0.dll
        C:\...\cygwin64\bin\cygkrb5-3.dll
          C:\...\cygwin64\bin\cygcom_err-2.dll
  C:\...\cygwin64\bin\cygpcre2-8-0.dll

$HOME\src\cygwin\git\git-2.28.0-1.x86_64\inst\usr\libexec\git-core\git-remote-http.exe
  C:\...\cygwin64\bin\cygcurl-4.dll
    C:\...\cygwin64\bin\cygbrotlidec-1.dll
      C:\...\cygwin64\bin\cygwin1.dll
        C:\Windows\system32\KERNEL32.dll
          C:\Windows\system32\ntdll.dll
          C:\Windows\system32\KERNELBASE.dll
      C:\...\cygwin64\bin\cygbrotlicommon-1.dll
    C:\...\cygwin64\bin\cygcrypto-1.1.dll
      C:\...\cygwin64\bin\cygz.dll
    C:\...\cygwin64\bin\cygidn2-0.dll
      C:\...\cygwin64\bin\cygiconv-2.dll
      C:\...\cygwin64\bin\cygintl-8.dll
      C:\...\cygwin64\bin\cygunistring-2.dll
    C:\...\cygwin64\bin\cyglber-2-4-2.dll
    C:\...\cygwin64\bin\cygldap-2-4-2.dll
      C:\...\cygwin64\bin\cygsasl2-3.dll
      C:\...\cygwin64\bin\cygssl-1.1.dll
    C:\...\cygwin64\bin\cygnghttp2-14.dll
    C:\...\cygwin64\bin\cygpsl-5.dll
    C:\...\cygwin64\bin\cygssh-4.dll
      C:\...\cygwin64\bin\cyggcc_s-seh-1.dll
      C:\...\cygwin64\bin\cyggssapi_krb5-2.dll
        C:\...\cygwin64\bin\cygk5crypto-3.dll
          C:\...\cygwin64\bin\cygkrb5support-0.dll
        C:\...\cygwin64\bin\cygkrb5-3.dll
          C:\...\cygwin64\bin\cygcom_err-2.dll
  C:\...\cygwin64\bin\cygpcre2-8-0.dll

$HOME\src\cygwin\git\git-2.28.0-1.x86_64\inst\usr\libexec\git-core\git-remote-https.exe
  C:\...\cygwin64\bin\cygcurl-4.dll
    C:\...\cygwin64\bin\cygbrotlidec-1.dll
      C:\...\cygwin64\bin\cygwin1.dll
        C:\Windows\system32\KERNEL32.dll
          C:\Windows\system32\ntdll.dll
          C:\Windows\system32\KERNELBASE.dll
      C:\...\cygwin64\bin\cygbrotlicommon-1.dll
    C:\...\cygwin64\bin\cygcrypto-1.1.dll
      C:\...\cygwin64\bin\cygz.dll
    C:\...\cygwin64\bin\cygidn2-0.dll
      C:\...\cygwin64\bin\cygiconv-2.dll
      C:\...\cygwin64\bin\cygintl-8.dll
      C:\...\cygwin64\bin\cygunistring-2.dll
    C:\...\cygwin64\bin\cyglber-2-4-2.dll
    C:\...\cygwin64\bin\cygldap-2-4-2.dll
      C:\...\cygwin64\bin\cygsasl2-3.dll
      C:\...\cygwin64\bin\cygssl-1.1.dll
    C:\...\cygwin64\bin\cygnghttp2-14.dll
    C:\...\cygwin64\bin\cygpsl-5.dll
    C:\...\cygwin64\bin\cygssh-4.dll
      C:\...\cygwin64\bin\cyggcc_s-seh-1.dll
      C:\...\cygwin64\bin\cyggssapi_krb5-2.dll
        C:\...\cygwin64\bin\cygk5crypto-3.dll
          C:\...\cygwin64\bin\cygkrb5support-0.dll
        C:\...\cygwin64\bin\cygkrb5-3.dll
          C:\...\cygwin64\bin\cygcom_err-2.dll
  C:\...\cygwin64\bin\cygpcre2-8-0.dll

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Ken Brown]

On 8/10/2020 9:27 PM, Brian Inglis wrote:
> On 2020-08-10 13:14, Ken Brown via Cygwin wrote:
>> On 8/10/2020 1:33 PM, Brian Inglis wrote:
>>> On 2020-08-10 08:52, Ken Brown via Cygwin wrote:
>>>> On 8/9/2020 5:48 PM, Brian Inglis wrote:
>>>>> On 2020-08-09 12:28, Adam Dinwoodie wrote:
>>>>>> On Fri, 24 Jul 2020 at 13:56, Adam Dinwoodie wrote:
>>>>>>> In the failing case, the `/configure` stage includes the following
>>>>>>> text: `configure: Setting CURL_LDFLAGS to '-lcurl -lnghttp2 -lidn2
>>>>>>> -lssh -lpsl -lssl -lcrypto -lldap -llber -lbrotlidec -lbrotlidec
>>>>>>> -lz'`; in the working case using -7.66.0-1, the corresponding line is
>>>>>>> just `configure: Setting CURL_LDFLAGS to '-lcurl'`.
>>>> [...]
>>>>> Meanwhile, that info likely comes from:
>>>>>
>>>>> $ tail -vn15 /lib/pkgconfig/libcurl.pc
>>>>> ==> /lib/pkgconfig/libcurl.pc <==
>>>>> #
>>>>> prefix=/usr
>>>>> exec_prefix=/usr
>>>>> libdir=${exec_prefix}/lib
>>>>> includedir=${prefix}/include
>>>>> supported_protocols="DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS LDAP LDAPS
>>>>> POP3 POP3S RTSP SCP SFTP SMB SMBS SMTP SMTPS TELNET TFTP"
>>>>> supported_features="SSL IPv6 UnixSockets libz brotli AsynchDNS IDN PSL NTLM
>>>>> NTLM_WB TLS-SRP HTTP2 HTTPS-proxy"
>>>>>
>>>>> Name: libcurl
>>>>> URL: https://curl.haxx.se/
>>>>> Description: Library to transfer files with ftp, http, etc.
>>>>> Version: 7.71.1
>>>>> Libs: -L${libdir} -lcurl
>>>>> Libs.private: -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto -lldap -llber
>>>>> -lbrotlidec -lbrotlidec -lz
>>>>> Cflags: -I${includedir}
>>>>>
>>>>> it looks like your git build should be using Libs for dynamic builds and adding
>>>>> Libs.private for static builds
>>>
>>>> If you look at configure.ac in the git sources, you'll see that it uses
>>>> curl-config, not pkg-config.  The former reports:
>>>>
>>>> $ curl-config --libs
>>>> -lcurl -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto -lldap -llber -lbrotlidec
>>>> -lbrotlidec -lz
>>>>
>>>> Yaakov's build of earlier versions of curl used a patch 7.33.0-libdeps.patch to
>>>> prevent the unnecessary libs from being listed.  He even had a comment at the
>>>> beginning of the patch, explaining the reason for it: "These are needed only for
>>>> static linking, but we build with --disable-static".
>>>
>>> I try to avoid looking at autotools plumbing if I can possibly avoid it! ;^>
>>> Someone cleaned up the approach used, as the patch did not apply and was dropped.
>>
>> My point is that the patch shouldn't have been dropped.  It should have been
>> modified to apply to the updated sources.  (I've done this.  See the attached.)
>> As Yaakov wrote, the patch is needed to prevent 'curl-config --libs' from
>> including libs that are only needed for static linking.
>>
>> With the modified patch applied, curl-config gives the expected result:
>>
>> $ curl-config --libs
>> -lcurl
>>
>>> If you look at my later post, cygport git build and tests worked for me with no
>>> problems other than at first missing some package build dependencies
>>
>> Those were not really build dependencies.  They only appeared to be needed
>> because 'curl-config --libs' erroneously included libs that are only needed for
>> static linking.
> 
> Your patch seems to reproduce exactly what is currently distributed in the
> libcurl-devel package:
> 
> $ tail -n7 /lib/pkgconfig/libcurl.pc
> Name: libcurl
> URL: https://curl.haxx.se/
> Description: Library to transfer files with ftp, http, etc.
> Version: 7.71.1
> Libs: -L${libdir} -lcurl
> Libs.private: -lnghttp2 -lidn2 -lssh -lpsl -lssl -lcrypto -lldap -llber
> -lbrotlidec -lbrotlidec -lz
> Cflags: -I${includedir}

Are you saying that you still get the Libs.private line in libcurl.pc if you 
rebuild the curl package with my patch?  That's not what I see.

> Perhaps I am misunderstanding: I was addressing the OP build issue; are you
> perhaps concerned solely with the correct operation of curl-config?

The OP build issue resulted from the incorrect operation of curl-config.  I gave 
you a patch that restores the operation of curl-config to the way it was in 
previous curl builds.  That should fix the OP build issue.

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

Ken

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Adam Dinwoodie]

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.

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.

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Brian Inglis]

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.

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

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Brian Inglis]

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

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-2

[Brian Inglis]

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.

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

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-2

[Adam Dinwoodie]

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!

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[ASSI]

Brian Inglis writes:
> - it complains that perl(DBD::SQLite) perl(IO::Pty) are not installed - how do
> these and your other perl module dependencies map to Cygwin packages?
> I also mean that in general - how can I map a perl module to a perl package and
> vice versa - for future info?

You go look up the distribution that provides this mocule on MetaCPAN
and then install perl-<distrib-name>.  Eventually though, such these
dependencies should be listed in the cygport file with their Cygwin
package names as BUILD_REQUIRES.


Regards
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Brian Inglis]

On 2020-08-10 23:15, ASSI wrote:
> Brian Inglis writes:
>> - it complains that perl(DBD::SQLite) perl(IO::Pty) are not installed - how do
>> these and your other perl module dependencies map to Cygwin packages?
>> I also mean that in general - how can I map a perl module to a perl package and
>> vice versa - for future info?
> 
> You go look up the distribution that provides this mocule on MetaCPAN
> and then install perl-<distrib-name>.  Eventually though, such these
> dependencies should be listed in the cygport file with their Cygwin
> package names as BUILD_REQUIRES.

Thanks Achim,

So the distribution names are the obvious perl-dbd-sqlite and perl-io-pty and
neither appear to be available from Cygwin?

The git.cygport specifies these as perl module names, which presumably
perl.cygclass handles?

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

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[ASSI]

Brian Inglis writes:
> So the distribution names are the obvious perl-dbd-sqlite and perl-io-pty and
> neither appear to be available from Cygwin?

Nah, perl distribution names are CamelCased and Cygwin keeps that
convention.  Also you didn't actually look up the distribution for
IO::Pty but just guessed.  So, correcting both mistakes will get you:
perl-DBD-SQLite and perl-IO-Tty.  These are Cygwin packages you can
install.

> The git.cygport specifies these as perl module names, which presumably
> perl.cygclass handles?

Yes, by trying to load the module from the current Perl installation.
In other words there's no check for any particular Cygwin package being
installed there at all.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [ANNOUNCEMENT] Updated: curl 7.71.1-1

[Brian Inglis]

On 2020-08-11 09:03, ASSI wrote:
> Brian Inglis writes:
>> So the distribution names are the obvious perl-dbd-sqlite and perl-io-pty and
>> neither appear to be available from Cygwin?
> 
> Nah, perl distribution names are CamelCased and Cygwin keeps that
> convention. Also you didn't actually look up the distribution for
> IO::Pty but just guessed.  So, correcting both mistakes will get you:
> perl-DBD-SQLite and perl-IO-Tty.  These are Cygwin packages you can
> install.

Looked up dist names on MetaCPAN but did not notice the unexpected switch from
-pty to -tty (read it as I expected to see it), nor considered case significant
in Cygwin package names (ugh!) - I use apt-cyg for many operations on 64 bit
except upgrades - apt-cyg needs updated to make search operations case insensitive.

>> The git.cygport specifies these as perl module names, which presumably
>> perl.cygclass handles?
> 
> Yes, by trying to load the module from the current Perl installation.
> In other words there's no check for any particular Cygwin package being
> installed there at all.

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