#1080972 guile-3.0: triggers lots of warnings in gnucash

Package:
guile-3.0
Source:
guile-3.0
Description:
GNU extension language and Scheme interpreter
Submitter:
Vincent Lefevre
Date:
2024-09-08 22:39:01 UTC
Severity:
normal
#1080972#5
Date:
2024-09-06 06:08:43 UTC
From:
To:
This latest version triggers lots of warnings in gnucash:

;;; WARNING: loading compiled file /usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/utilities.go failed:
;;; In procedure load-thunk-from-memory: incompatible bytecode version
;;; WARNING: loading compiled file /usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/utilities.go failed:
;;; In procedure load-thunk-from-memory: incompatible bytecode version
;;; WARNING: loading compiled file /usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/core-utils.go failed:
[...]
#1080972#10
Date:
2024-09-06 06:19:24 UTC
From:
To:
And in particular, it makes the loading very slow.
#1080972#15
Date:
2024-09-07 22:43:07 UTC
From:
To:
Vincent Lefevre <vincent@vinc17.net> writes:

Did you ever install the (unstable only) 3.0.10 package?  Unfortunately
we had to downgrade it because it isn't compatible with 32-bit
architectures.  (Presumably that'll be fixed in 11).

Was just wondering if that was causing unexpected errors and
auto-re-compilation, and if gnucash was built against that version
(don't know how it handles its .go files), then that might also be
related.
#1080972#20
Date:
2024-09-08 11:05:09 UTC
From:
To:
Yes, it was installed in June. This version had been in unstable
for about 2 months.

The current gnucash version is

gnucash (1:5.8-1) unstable; urgency=medium

  * New upstream release.
    + fixed FTBFS in "gtest-gnc-int128.cpp" (Closes: #1077415).
#1080972#25
Date:
2024-09-08 11:10:42 UTC
From:
To:
Note that gnucash has un unversioned dependency on guile packages:

  guile-3.0 | guile-2.2 | guile-2.0
#1080972#30
Date:
2024-09-08 21:26:57 UTC
From:
To:
Vincent Lefevre <vincent@vinc17.net> writes:

Ahh, OK, then I suspect this may be a gnucash package issue, i.e. needs
a rebuild/upload after the downgrade (if it's including compiled files).
#1080972#35
Date:
2024-09-08 22:35:08 UTC
From:
To:
[Cc'ing the gnucash maintainer. As a summary, the downgrade of the
guile-3.0 packages to upstream's 3.0.9 with 3.0.10+really3.0.9-1
prevents gnucash from using the compiled files, with consequences:
lots of warnings and slowness.]

I can see in libguile/loader.c:

            uint16_t major = dyn[i].d_un.d_val >> 16;
            uint16_t minor = dyn[i].d_un.d_val & 0xffff;
            switch (major)
              {
              case 0x0300:
                bytecode_kind = BYTECODE_KIND_GUILE_3_0;
                if (minor < SCM_OBJCODE_MINIMUM_MINOR_VERSION)
                  return "incompatible bytecode version";
                if (minor > SCM_OBJCODE_MINOR_VERSION)
                  return "incompatible bytecode version";
                break;
              default:
                return "incompatible bytecode kind";
              }
            break;

I suppose that the compatiblity of gnucash with the major version is
ensured by the dependency on guile-3.0-libs.

There can still be issues if
  * gnucash is upgraded by the user while guile-3.0-libs has not been
    upgraded yet (e.g. due to a major bug or a dependency that blocks
    the guile-3.0-libs upgrade);
  * if SCM_OBJCODE_MINIMUM_MINOR_VERSION is increased, and gnucash
    is not upgraded at the same time as guile-3.0-libs.

So, to ensure that everything is fine in the future, shouldn't
gnucash depend on the exact guile-3.0-libs version against which
it has been built?

Alternatively, if SCM_OBJCODE_MINOR_VERSION doesn't change often,
shouldn't guile-3.0-libs provide virtual packages that correspond
to the supported bytecode versions (so that packages that distribute
compiled files could depend on the one that corresponds to the
build)? Thus this dependency would ensure that the above conditions
on minor are satisfied, without being too strict.