Problem with 32-bit ubuntu builds?

[mtorpey]

Over in the Digraphs package, we're having trouble running our ubuntu32 tests. There's a failure when APT tries to install 32-bit dependencies.

It looks like the problem happens when this part is run:

https://github.com/gap-actions/setup-gap/blob/44a8ae68e262dd0d22b84ef146460741b4c06c70/action.yml#L37C1-L66

See the build log under "Install GAP and clone/compile necessary packages". This started a few days ago, and now causes failures on commits that previously passed.

Possibly due to a change in the Ubuntu repos?

[mtorpey]

The bug shows as:

The following packages have unmet dependencies:
 libc6:i386 : Depends: libgcc-s1:i386 but it is not going to be installed
 libgmpxx4ldbl:i386 : Depends: libgcc-s1:i386 (>= 3.0) but it is not going to be installed
                      Depends: libstdc++6:i386 (>= 5.2) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
Error: Process completed with exit code 100.

if that helps.

[fingolfin]

Recent Ubuntu versions mostly dropped 32bit support, as in: most packages only have a 64bit version. As a result, for GAP we simply gave up trying to test 32bit Ubuntu in our CI tests.

[mtorpey]

Understood! I wondered whether 32-bit support would disappear eventually.

This bit of code still has explicit cases for ABI=32. Should those be removed, or is there an alternative to Ubuntu where it still works?

[fingolfin]

Didn't see Michael's last question there, sorry. Short answer: I don't know of an alternative; it may be possible to do this by using a docker imager or something like that in the CI job, but I never looked into it, and don't plan to -- 32bit support is completely irrelevant for me, so I don't want to spend time on it (though if someone figures out a way to do it, I'd be happy to review relevant PRs here or for gap-system/gap)

[limakzi]

Do we want to keep support for 32-bit architectures?

[fingolfin]

I think it is fine to drop 32bit support (or rather: support for testing in 32bit mode) these days. It gets harder and harder to setup testing for that.

To clarify the above: I don't see reason to remove code that supports 32bit mode right now, but testing it is not worth it if it requires a lot of effort to keep working, and that's how it looks like.

[limakzi]

@fingolfin, @mtorpey I agree, but instead I would add arm-builds.