Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
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 On 4/10/24 14:59, Aaron M. Ucko wrote: Steven Eker writes: 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). 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!
Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
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 On 4/9/24 00:01, Sebastian Ramacher wrote: Hi Steven On 2024-04-08 15:38:50 -0700, Steven Eker wrote: 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. This sounds like it needs to fixed in GMP then. https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Year_2038_problem__;!!DZ3fjg!--tzUBTnQHRKfnkc8PqaPE5gHxPm2QWswg2_MWTbLaWxFFDXu6jiPCjltocalTdckv2oG8G8tDajml0HNO6JIFyo$ https://urldefense.com/v3/__https://gmplib.org/manual/C_002b_002b-Interface-Integers__;!!DZ3fjg!--tzUBTnQHRKfnkc8PqaPE5gHxPm2QWswg2_MWTbLaWxFFDXu6jiPCjltocalTdckv2oG8G8tDajml0HNHAQQdRg$ I'm not happy converting a signed value to an unsigned value for all architectures. But mpz_class nanoSeconds(static_cast(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. And this does not sound like a fix which we want. Best Sebastian
Bug#1067957: [EXTERNAL] Re: [[maude-bugs]] Maude fails to build on armhf
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(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 On 4/7/24 08:28, Nilesh Patra wrote: On Sun, Apr 07, 2024 at 07:45:33PM +0530, Nilesh Patra wrote: Hi, Maude fails to build on armhf/arm32 arch with: 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); | ^ In file included from ../../src/BuiltIn/succSymbol.hh:28, from timeManagerSymbol.cc:53: /usr/include/gmpxx.h:1646:3: note: candidate: ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(double)’ 1646 | __GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS | ^~ /usr/include/gmpxx.h:1646:3: note: candidate: ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(float)’ Full long here: https://buildd.debian.org/status/fetch.php?pkg=maude=armhf=3.4-1=1712489526=0 And Debian bug report here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067957 Would be great if you have the cycles to look into it. 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, )); Assert(r == 0, "clock_gettime() failed: " << strerror(errno)); - mpz_class nanoSeconds(timeValue.tv_sec); + mpz_class nanoSeconds(static_cast(timeValue.tv_sec)); nanoSeconds *= BILLION; nanoSeconds += timeValue.tv_nsec; Best, Nilesh
