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.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple