Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
Steven Eker <[email protected]>
| Newsgroups | gmane.linux.debian.devel.bugs.general,gmane.linux.debian.devel.medical |
|---|---|
| Message-ID | <[email protected]> |
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<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. > And this does not sound like a fix which we want. > > Best > Sebastian