Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
Control: severity -1 wishlist 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. On Thu, Apr 11, 2024 at 07:53:08AM +0200, Andreas Tille wrote: > Hi, > > Am Wed, Apr 10, 2024 at 03:33:53PM -0700 schrieb Steven Eker: > > 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); > > 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. > > > 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. > > Raspian is based on Debian and if the 32bit ARM architectures fail here > Raspian people have a problem. > > Kind regards >Andreas. > > -- > https://fam-tille.de > Best, Nilesh signature.asc Description: PGP signature
Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
Hi, Am Wed, Apr 10, 2024 at 03:33:53PM -0700 schrieb Steven Eker: > 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); 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. > 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. Raspian is based on Debian and if the 32bit ARM architectures fail here Raspian people have a problem. Kind regards Andreas. -- https://fam-tille.de
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
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! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
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. -- https://fam-tille.de
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
