https://buildd.debian.org/status/fetch.php?pkg=maude&arch=armhf&ver=3.2-2%2Bb1&stamp=1711717901&raw=0

In file included from timeManagerSymbol.cc:64:
timeActions.cc: In member function ‘void
TimeManagerSymbol::getTimeSinceEpoch(FreeDagNode*,
ObjectSystemRewritingContext&)’:
timeActions.cc:43:41: error: call of overloaded ‘__gmp_expr(__time64_t&)’ is
ambiguous
   43 |   mpz_class nanoSeconds(timeValue.tv_sec);
      |                                         ^

We believe that the bug you reported is fixed in the latest version of
maude, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1067957@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Nilesh Patra <nilesh@iki.fi> (supplier of updated maude package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 07 Apr 2024 16:28:11 +0530
Source: maude
Architecture: source
Version: 3.4-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team <debian-med-packaging@lists.alioth.debian.org>
Changed-By: Nilesh Patra <nilesh@iki.fi>
Closes: 1067957
Changes:
 maude (3.4-1) unstable; urgency=medium
 .
   * Team Upload.
   * New upstream version 3.4 (Closes: #1067957)
   * Refresh, update patches
   * Drop patch file
   * Update Builddep from libncurses5-dev => libncurses-dev
     (former is a virtual package)
   * Bump Standards-Version to 4.6.2 (no changes needed)
   * Remove copyright for superfluous file
Checksums-Sha1:
 250e0c8f7b749f5e31ef7711821d820d27e6f6a8 1387 maude_3.4-1.dsc
 fdd386d89b978a5193aacde26dd6cf883d1f360a 2660916 maude_3.4.orig.tar.gz
 097237c3d76b0684126108440fbbeb6655ba49a7 6544 maude_3.4-1.debian.tar.xz
 9ffc04f6d2744686754642346a6bafacd5b97959 6883 maude_3.4-1_source.buildinfo
Checksums-Sha256:
 8612b0072ed70f01b992528ce4a18f76c96aab52b264f475c7420ecd4b57a55f 1387 maude_3.4-1.dsc
 2175845809a1dfcf0da4d4adf709cea4b933859d3d37e012b4edb09f97514fca 2660916 maude_3.4.orig.tar.gz
 91cd6595e04bb058cdc6154cd86931dfd2ec88d6dc207744fa5f3f2df2b36764 6544 maude_3.4-1.debian.tar.xz
 b4fc1988fcf65b4ba0add7d0dab72f59618e385b633fd133d7217f635d92b0e4 6883 maude_3.4-1_source.buildinfo
Files:
 b5bf1b95c73d39781a97482170561b0f 1387 science optional maude_3.4-1.dsc
 97c92148c42d6b78efc645d64f00e910 2660916 science optional maude_3.4.orig.tar.gz
 0421b2f2d2854aa2d3d3cd0acdd4b824 6544 science optional maude_3.4-1.debian.tar.xz
 bfa4e93dc509ca214d09cbdd980e0260 6883 science optional maude_3.4-1_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQSglbZu4JAkvuai8HIqJ5BL1yQ+2gUCZhJ8wAAKCRAqJ5BL1yQ+
2kLbAP4y5OnBa6kxFk+YBJ57lGilrViQ5AZUW1ED1Mh5WOJ7JgD9EtjYA9j826Bq
nJGNoRaO4PcoWIKkTTtqr6dimydG+wU=
=RzXW
-----END PGP SIGNATURE-----

Control: reopen -1

It failed the same way with 3.4-1: https://buildd.debian.org/status/fetch.php?pkg=maude&arch=armhf&ver=3.4-1&stamp=1712489526&raw=0

Cheers

This patch fixes the issue at hand but I am unsure if it is sensible to apply
it.

diff --git a/src/ObjectSystem/timeActions.cc b/src/ObjectSystem/timeActions.cc
index 77395aa..63aa028 100644
--- a/src/ObjectSystem/timeActions.cc
+++ b/src/ObjectSystem/timeActions.cc
@@ -40,7 +40,7 @@ TimeManagerSymbol::getTimeSinceEpoch(FreeDagNode* message, ObjectSystemRewriting
   DebugSave(r, clock_gettime(CLOCK_REALTIME, &timeValue));
   Assert(r == 0, "clock_gettime() failed: " << strerror(errno));

-  mpz_class nanoSeconds(timeValue.tv_sec);
+  mpz_class nanoSeconds(static_cast<unsigned long>(timeValue.tv_sec));
   nanoSeconds *= BILLION;
   nanoSeconds += timeValue.tv_nsec;


Best,
Nilesh

Hi Nilish,

I don't have a 32-bit machine to test on, but my understanding is that
Linux has moved to a 64-bit signed integer for time_t and this is a long
long on 32-bit machines which is explicitly not supported by GMP's C++ API.

https://en.wikipedia.org/wiki/Year_2038_problem
https://gmplib.org/manual/C_002b_002b-Interface-Integers

I'm not happy converting a signed value to an unsigned value for all
architectures. But

   mpz_class nanoSeconds(static_cast<Index>(timeValue.tv_sec));

should fix the problem, at least until 2038. Can you check that this
works? If so I'll put it in the next public alpha.

Steven

Hi Steven

This sounds like it needs to fixed in GMP then.

And this does not sound like a fix which we want.

Best
Sebastian

Hi Sebastian,

The lack of long long support in GMP has been the subject of some
discussions:

https://gmplib.org/list-archives/gmp-bugs/2020-June/thread.html#4771
https://gmplib.org/list-archives/gmp-discuss/2021-January/thread.html#6625

I don't see it happening soon - it took years for the x18 issue on Apple
silicon to be fixed.
In my development version I've modified the code to:

   Index seconds = timeValue.tv_sec;  // this is 32-bit on 32-bit
machines so mpz_class constuctor is defined
   mpz_class nanoSeconds(seconds);
   nanoSeconds *= BILLION;
   nanoSeconds += timeValue.tv_nsec;

This is harmless on 64-bit architectures since Index will be a signed
64-bit integer and if it works on 32-bit architectures, it's a work
around until GMP is fixed (hopefully before 2038).

Steven

Hi,

I'd suggest to set

  Build-Depends: architecture-is-64-bit, architecture-is-little-endian

and remove 32bit architectures of maude.

Kind regards
   Andreas.

Steven Eker <eker@csl.sri.com> writes:

I know this suggestion is unorthodox, and quite possibly moot at this
point in the context of official Debian packages -- but you might want
to consider formally going through double here, at least on the relevant
platforms.  Precision loss shouldn't be a concern for another 140
million years or so by my reckoning, and I expect the additional
conversion overhead would be negligible in practice.

Thanks!

I like that solution since I believe there are 64-bit platforms where
long is 32-bits. I've updated my development version thus:

   //
   //    timeValue.tv_sec is 64-bit since Linux kernel 5.6 but GMP
doesn't yet have support
   //    for long long which is a problem on platforms where long is
less than 8 bytes.
   //
#if SIZEOF_LONG < 8
   double seconds = timeValue.tv_sec;
#else
   long seconds = timeValue.tv_sec;
#endif
   mpz_class nanoSeconds(seconds);

Of course I expect to drop support for 32-bit before 2038 - certainly
when one our dependencies drops support. But I've gotten a bug report
for building Maude on a Raspberry Pi.

Steven

Hi,

Am Wed, Apr 10, 2024 at 03:33:53PM -0700 schrieb Steven Eker:

Sounds like some working solution.  It would help if you could tag a new
released to enable us fetching a fresh tarball incorporatinig this
change.

Raspian is based on Debian and if the 32bit ARM architectures fail here
Raspian people have a problem.

Kind regards
   Andreas.

Hi,

maude has been -rm'ed on 32-bit archs as per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068766
So this issue is now moot and I am downgrading the severity.
Best,
Nilesh