On Sun, Jul 28, 2024 at 3:33 PM Dirk Eddelbuettel <e...@debian.org> wrote: > > > On 28 July 2024 at 15:11, Cottrell, Allin wrote: > | On Sun, Jul 28, 2024 at 1:29 PM Dirk Eddelbuettel <e...@debian.org> wrote: [...] > | > | > ../lib/src/interact.c: In function 'open_append_stage_1': > | > | > ../lib/src/interact.c:2131:19: error: implicit declaration of > function 'try_http' [-Wimplicit-function-declaration] > | > | > 2131 | err = try_http(cmd->param, op->fname, NULL); > | > | > | ^~~~~~~~ > | > | > make[2]: *** [Makefile:327: interact.lo] Error 1 > | > > | > That looks like one of the simple issues where the newer compiler (and I > | > checked that this was gcc-14) is pickier about includes. > | > > | > Allin: Have you seen this already upstream, and better still, fixed > already? > | > | Hmm, try_http() is declared in lib/src/gretl_www.h, which is included > | in interact.c provided that USE_CURL is defined. And in a full build > | of gretl I'd expect USE_CURL to be defined; without that we drop all > | internet interaction. I guess it's a bug that the call to try_http() > | in interact.c is not itself guarded by USE_CURL, and that's now done > | in git. If that doesn't solve the problem, the question that arises is > | why USE_CURL is (apparently) not getting defined. > > Good catch, and analysis. > > We always turn curl on in the Debian builds. I have a build-depends on > libcurl4-gnutls-dev | libcurl4-dev > and the libgretl package depends on > libcurl3t64-gnutls (>= 7.56.1) > (where thr t64 suffix is for a Debian-internal transition we did to become > 'year 2038' resistant by switching to 'bigger' time types). > > So that sounds like you spot on that maybe the file in question did not have > #define guards, the older compiler was tolerant but gcc-14 nags?
Actually, no. I checked with gcc version 14.1.1 20240720 on Arch and got no error or warning, while the build log at http://qa-logs.debian.net/2024/07/27/gretl_2024b-1_unstable.log shows, among other output from the configure script: checking for CURL... no So it was the actual bug (now fixed in git) where USE_CURL was not defined but try_http() was referenced, not a virtual/potential bug whereby the compiler somehow detected that try_http() _could_ in principle be referenced without USE_CURL being defined. So why did the CURL check fail? Well, in configure.ac the check is: PKG_CHECK_MODULES(CURL, libcurl >= 7.13.0, have_curl="yes", have_curl="no") Do you have an idea why this could now be failing when it didn't before? Allin
