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.
Ken
--- origsrc/curl-7.71.1/tests/libtest/Makefile.am 2020-06-27
18:03:53.000000000 -0400
+++ src/curl-7.71.1/tests/libtest/Makefile.am 2020-08-14 14:33:04.434364600
-0400
@@ -118,7 +118,7 @@ if BUILD_STUB_GSS
noinst_LTLIBRARIES += libstubgss.la
libstubgss_la_CPPFLAGS = $(AM_CPPFLAGS)
-libstubgss_la_LDFLAGS = $(AM_LDFLAGS) -avoid-version -rpath /nowhere
+libstubgss_la_LDFLAGS = $(AM_LDFLAGS) -avoid-version -rpath /nowhere
-no-undefined
libstubgss_la_CFLAGS = $(AM_CFLAGS) -g
libstubgss_la_SOURCES = stub_gssapi.c stub_gssapi.h
