4.3.0 fails to build on 32bit

[AdrianBunk]

https://buildd.debian.org/status/logs.php?pkg=form&ver=4.3.0-1

reken.c: In function ‘Moebius’:
reken.c:3752:28: error: ‘struct R_const’ has no member named ‘numinprimelist’
 3752 |         for ( i = 0; i < AR.numinprimelist; i++ ) {
      |                            ^
reken.c:3753:23: error: ‘struct R_const’ has no member named ‘PrimeList’
 3753 |                 x = AR.PrimeList[i];
      |                       ^

@vermaseren Commit 0da2724 lacks an #if ( BITSINWORD == 32 ) similar to other code in this file, that is necessary due to commit 768b2d6.

[tueda]

To check such pitfalls of 32-bit builds, probably we need to resurrect 32-bit build tests in our continuous integration environment, which was lost during the transition from Travis CI to GitHub Actions (#361).

[tueda]

I have added a CI job with a 32-bit container, which fails due to this Moebius build error, as expected (log).

In local environments without Docker, one may try cross-compiling to test for building. For example, with zig 0.10 (on 64-bit Ubuntu 20.04 on WSL2), I can configure like

CC='zig cc -target i386-linux-gnu.2.28' CXX='zig c++ -target i386-linux-gnu.2.28' ./configure --build=x86_64-pc-linux-gnu --host=i386-pc-linux-gnu

though the resultant executables don't run on my machine (because I haven't installed 32-bit runtime libraries on that machine).

[sirving]

The question that comes to my mind is does supporting a 32 bit version make sense?

What is the benefit of a 32 bit version? What is the downside of getting rid of this support? How many users?

What is the added level of work and complexity to support the 32 bit version?

I don't know the answers to the above questions, but it would be worth considering this. If there are only a few users it may be cost effective for them to upgrade to using the 64 bit version.

[alexmyczko]

Unfortunately Debian popcon does not show which arches: https://qa.debian.org/popcon.php?package=form

But Microsoft Windows, macOS got rid of 32-bit, so did my workplace (at least 5 years ago if not 10)

And here is that other architectures:
https://buildd.debian.org/status/package.php?p=form&suite=sid

which according the main popcon page are hardly used:
https://popcon.debian.org/

[AdrianBunk]

Raspberry Pi OS (based on Debian) was 32bit-only until 2 years ago, the original Raspberry Pi 1 and the cheapest Raspberry Pi Zero hardware do not support 64bit (but the latest Raspberry Pi Zero 2 W supports 64bit).

32bit is still popular in lower end embedded Linux.

There are more people using old/vintage hardware than many people think (Debian still has working unofficial m68k and hppa ports).

[vermaseren]

I gave the Raspberry Pi as an example of portability. Definitely not for running because what it used to replace a hard disk. That would wear out very quickly with Form. Using old style computers is not very efficient considering the target group of Form users. And considering that there are very few Form developers we have to draw a line somewhere. There will be a Form developer workshop April 12,13,14 2023 in Madrid for experienced Form users, to teach them about the internals of Form and how to make additions, fix bugs etc. Web page: https://inspirehep.net/conferences/2609711 but it still needs a bit of information about the bank account and the hotel. That should be available in a few days. Hence currently the registration is still closed.

…

On 6 Dec 2022, at 11:38, Adrian Bunk ***@***.***> wrote: Raspberry Pi OS (based on Debian) was 32bit-only until 2 years ago, the original Raspberry Pi 1 and the cheapest Raspberry Pi Zero hardware do not support 64bit (but the latest Raspberry Pi Zero 2 W supports 64bit). 32bit is still popular in lower end embedded Linux. There are more people using old/vintage hardware than many people think (Debian still has working unofficial m68k and hppa ports). — Reply to this email directly, view it on GitHub <#422 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJPCEVMPKTC4WNU4OJW6ODWL4JTXANCNFSM6AAAAAASGT3LPU>. You are receiving this because you were mentioned.

[AdrianBunk]

@vermaseren I was replying to @alexmyczko regarding where remaining 32bit use in general is still today (on Linux and especially on Debian).

It is not clear to me why Form has 32bit specific codepaths at all.
Today the compromise is often that code is portable, but fast only on commonly used hardware. E.g. doing math with uint64_t works also on 32bit, but is fast only on 64bit.
But scientific software without remaining reasonable 32bit usecases often ends up being 64bit only, if writing portable code is hard for some reason.

[vermaseren]

The differences in code for 32 versus 64 bits is in the sizes of a FORM WORD etc. Translation to gmp is sensitive to that, but that has been done long ago. The issue recently surfaced with the moebius_ function which uses prime number lists which are different in length between the 32 and 64 bit versions and I kind of overlooked that. I still have to fix that. But also with version 5, when we get arbitrary precision floating point, there would be a translation problem. Hence my idea was to drop the whole 32 bits stuff. Alternatively we have to change the WORD sizes in the 32 bits version and also LONG -> long long. But there are a very few places using long long and those would need attention. It is probably possible and maybe not too much work. It would need extensive testing though. And all files and expressions on 32 bit systems would need almost twice as much space. And of course old .sav files might not be valid any longer, although we did make an effort in the past to make that more or less portable.

…

On 7 Dec 2022, at 12:49, Adrian Bunk ***@***.***> wrote: @vermaseren <https://github.com/vermaseren> I was replying to @alexmyczko <https://github.com/alexmyczko> regarding where remaining 32bit use in general is still today (on Linux and especially on Debian). It is not clear to me why Form has 32bit specific codepaths at all. Today the compromise is often that code is portable, but fast only on commonly used hardware. E.g. doing math with uint64_t works also on 32bit, but is fast only on 64bit. But scientific software without remaining reasonable 32bit usecases often ends up being 64bit only, if writing portable code is hard for some reason. — Reply to this email directly, view it on GitHub <#422 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJPCESPM2VT3MUV2WKRQODWMB2VLANCNFSM6AAAAAASGT3LPU>. You are receiving this because you were mentioned.

[tueda]

Though the necessity of the 32-bit version is still arguable, I have pushed a simple patch to fix the build failure. So, I close this issue.

For further comments on the 32-bit vs. 64-bit discussion, I suggest #426.

If the 32-bit moebius_ is still broken for any corner case, please comment on #430.