Re: [EXTERNAL] Re: [[maude-bugs]] Maude fails to build on armhf

Steven Eker <[email protected]>
Newsgroups gmane.linux.debian.devel.medical
Message-ID <[email protected]>
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

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&arch=armhf&ver=3.4-1&stamp=1712489526&raw=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, &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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.