On 28 July 2024 at 20:52, Cottrell, Allin wrote:
| 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?

Hm. Checking my last local build here (where I have a decade+ of local build
logs) for the most recent 2024b-1 build:

checking for FFTW... yes
checking for CURL... yes
checking for GLIB... yes

So not sure why I would have it, but Lucas in his bulk rebuild does not?

checking for FFTW... yes
checking for CURL... no
checking for GLIB... yes

Lucas, any idea?

Best, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Reply via email to